Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Eyck

  1. Eyck

    Checking ports for power estimations

    Well this a little bit about data representation. old_data is a pointer to a uint8_t and this is what you see in the variables view. It has the value of 0x7ff..fdb10. The memory at this address is 2 which is the lowest byte of the first element in your struct (x of type int). Actually using the struct the compiler orders the 2 elements in a row. Depending on the platform and the compiler the members might be 32 or 64 bit long. Lets assume the int is 32bit and the long is 64 (gcc on 64bit Linux). The layout is as follows (the suffix denote the byte number): old_data -> x.0 x.1 x.2 x.3 y.0 y.1 y.2 y.3 y.4 y.5 y.6 y.7 So the value 2 is the lowest byte of the old_val.x variable having the value of 2 (or 258,...) Well, the struct shown above is not entirely correct. The compiler might choose to put padding bytes inbetweeen the members for performance reasons. In this case above there will be 4 byte of padding between x and y so that y is at an aligned address (a multiple of 8). So you would declare it as struct __attribute__ ((__packed__)) my_data { int x; long y; }; to avoid the paddng. See also https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attributes Back to your question: you use the pointer like in an array. the notion *(old_data+i) is equivalent to old_data[i] So in the for loop you iterate over every byte belonging to the struct. BR
  2. This message indicates that you link 2 libraries or object files into one executable which are build against 2 different versions/configurations of the SystemC library. Actually this (or a similar) symbol created during the build of libsystemc and part of the libsystemc. It ensures that the header configuration and the compiled library match. It does not relate to TLM at all. One reason could be an inconsistence wrt the use of C++11, see here: https://stackoverflow.com/questions/46875731/setting-up-a-systemc-project-with-cmake-undefined-reference-to-sc-core Best regards
  3. Eyck

    Checking ports for power estimations

    I'm not sure if I get your first question right. Essentially this is a C++ question. But what you could do is a type erase of your (POD) data, use it as a byte array and count the changed bits using XOR (be carefull to you plain data, no classes). Something like: struct my_data { int x; long y; }; my_data old_val, new_val; uint8_t* old_data = reinterpret_cast<uint8_t*>(&old_val); uint8_t* new_data = reinterpret_cast<uint8_t*>(&new_val); unsigned toggles=0; for(size_t i=0; i<sizeof(my_data); ++i){ uint8_t diff = *(old_data+i)^*(new_data+i); uint8_t mask=1; for(size_t j=0; j<8; ++j, mask<<=1) if(mask&diff) ++toggles; } Regarding your second question: you transport the data via a signal which implements the signal_in_if. This interface has a value_changed_event() getter which returns an event firing when the value of the signal changes. Just wait for this event.
  4. What you can do is build your driver software as a shared library with a main function. In a SC_THREAD you just load the library and execute the main function. Along with this you have to implement a few utility functions (read, write, wait) which interact with the SystemC kernel or your DUT and being used by the main function (and the called functions from there). This is called host based or host compiled simulation (you may check the search engine of your choice for it). With some infrastructure it is even possible to mimic interrupt. Another option is to use some instruction set simulator (e.g. QEMU, DBT-RISE-RISCV, or some commercial alternatives) and do you driver development using a virtual prototype... Best regards
  5. There is no predefined way. You would have to have No_OF_SUBMODULES sc_signal<bool> connecting to the sc_out<bool>, one sc_signal<sc_dt::sc_uint<No_OF_SUBMODULES>> connecting to the sc_in<..>, and a SC_METHOD. The method needs to be sensitive to the bool signals, assemble the sc_uint and write it to the sc_uint signal. HTH
  6. See the answer to your other post. In a few words it describes the duration of the phase and saves a second call just to mark the end of the phase. Best regards
  7. The 10ns tells the initiator that the request phase (or address phase in some bus protocols) takes 10ns. During 110ns and 150ns simulation time the target executes the read. The 5ns in the BEGIN_RESP/END_RESP tells the target that the data/status transfer over the bus (the data phase on some bus protocols) takes 5ns. The annotated times in the return path is to save a second function call (END_REQ and END_RESP respectively) at two more simulation time points (120ns and 155ns). This way you can increase the performance of the simulation. Best regards
  8. BEGIN_REQ/END_REQ and BEGIN_RESP/END_RESP mark time points in the protocol. So in the stanndard implementation you have 2 phases: request and response. Depending on the type of access various data is been transferred: for a read REQ usually carries the addr while RESP carries the data and status while during a write REQ carries addess and data while RESP just carries the status. It is up to the initiator and target to care for consistency of the data in the payload, in most implementations I''ve seen the data is sampled/set at the BEGIN_* time point. Best regards
  9. As you might know TLM2.0 defines forward and backward interfaces. Those have default implementations in the simple initiator/target sockets. They are fine for many case (e.g. get_direct_mem_ptr() denies DMI) but if you need to change/customize the behavior you can register appropriate functions here. Best regards
  10. Just looked further: there is a typo in case 1. It should read //bind for(int i=0;i<3;i++){ objA->initiator_socket[i]->bind(*(objB->target_socket[i])); } as you use an array of pointers. Again, sc_vector eases your life: //Model A sc_core::sc_vector<tlm_utils::simple_initiator_socket_tagged<ModelA>> initiator_socket; ... // Model B sc_core::sc_vector<tlm_utils::simple_target_socket_tagged<ModelB>> target_socket; ... //bind for(int i=0;i<3;i++){ objA->initiator_socket[i].bind(objB->target_socket[i]); } The same applies to case 2: //bind objA->initiator_socket1->bind(*(objB->target_socket2)); objA->initiator_socket2->bind(*(objB->target_socket3)); objA->initiator_socket3->bind(*(objB->target_socket1)); Best regards
  11. In case 1 you should use sc_core::sc_vector<..> instead of a plain array as you cannot call constructors for plain arrays (what sc_vector does). Given that objA and objB are pointers case 1 is ok and works also with the sc_vector. Case 2 is fine as far as I see... Best regards
  12. Eyck

    Drive SCModel from a C-Shell

    Actually you don't assign anything to adata->sdata in sc_main In your if branch testing the pointer for NULL and create the design but then you throw away the pointer. So it is called a second time after calling sc_start() and it is not allowed to instantiate primitive channels after the elaboration phase. But in genereral your approach is quite a mess and prone to errors (as you encountered already). Why don't you put your outer for-loop in sc_main and just load the model from the shared librar? This way you have proper initialization, do not abuse any parameters and have a similar flexibility (as I can judge). Moreover you have some compatibility with other (commercial) SystemC simulators. Another aspect: repeatedly calling sc_elab_and_sim() has quite some perfomance impact as there are memory allocations to hold copies the argc[] strings and some more. Best regards
  13. Hi, there is no way to do this easily. Actually you have 32 output ports and 1 input port. So you need to connect the output ports to 32 bool signals and the input port to a uint32_t signal as well and make a SC_METHOD sensitive to all of the 32 bool signals. Within that method you iterate over the 32 bool signals and collect them into a 32bit value. BTW, having a POD array of ports is not preferable, I would use 'sc_core::sc_vector<sc_core::sc_out<bool>> out;'. This way you gain several things: the ports are initialized with a name based on the sc_vector instance name and you can bind a vector of ports to a vector of signals with a single line statement. Best regards
  14. Actually in the demo part of the tutorial 'Efficient use of Virtual Prototypes in Hardware/Software Development and Verification' (slides are here) there is exactly such a case show-cased. If you go to https://git.minres.com/DVCon2018/RISCV-VP/src/branch/develop/platform/src/rtl/spi_rtl.cpp you will find a class called rtl which instantiates a verialted RTL, a bus-functional model (BFM) of the TileLink protocol, and a few more converters adapting the RTL signals. The respcetive header can be found at https://git.minres.com/DVCon2018/RISCV-VP/src/branch/develop/platform/incl/sysc/rtl The BFM implements non-blocking transport where the target socket mixin (which is similar to simple_target_socket) does the translation from blocking to non-blocking if needed. This is just since the TIleLink protocol has an explicit request and response channel (similar to AXI). In case of loosely timed model the blocking access with wait() will break your quantum thus syncronizing the time. Having several initiators with different annotated time will then change the order of accesses. You treat speed for accuracy... I hope this gives you some idea. If you have further questions feel free to ask. Best
  15. Eyck

    Read in customized structs

    Well, if this is in the same method then you won't see the update as there is not delta cylce in between. You would see it if you put it in a SC_THREAD and put a wait(SC_ZERO_TIME); between the write() and the read() of p1 and p2
  16. Eyck

    sc_port zero copy?

    There will only be one copy initialized: slave_port, simple_bus_slave_if will not be instantiated (which usually is even not possible as those are in the common case pure virtual classes). N just defines how many interface can be bound at most, 0 means unlimited. Internally there is a vector holding pointers to the simple_bus_slave_if , no copies. The vector will be resized as soon as you bind an interface. Best regards
  17. Eyck

    Read in customized structs

    Where did you check the values of p1 and p2? write() only schedules the values to be written, you will see the actual value in the next delta cycle. Best regards
  18. Eyck

    Temporal Decoupling

    Well, the principle is fairly straightforward but the implications are not. The basic idea is: you have part(s) of the design (a domain) running with its own time . A domain not just uses the simulation time rather also holds an (positive) offset to this and manages it; basically the domain might be ahead of the simulation time. If you now have a communication from the domain to the rest of the simulation (e.g. a tlm transaction to a target) the initiator (within the domain) sends the offest along with all of its interactions with the system. As long as the target can answer without synconizing to the simulation (a typical example would be a memory without side effects) it just adds the delays to the annotated time and returns it to the initiator. This allows to execute quite some time within the domain without returning to the simulation kernel. This way context swithes are avoided and the simulation can run fiaster. Actually I'm not aware of a simple example of this. A fairly complete one can be found at a DVCon Europe tutorial (slides at https://www.minres.com/#pub, source at https://git.minres.com/DVCon2018/RISCV-VP) Best regards
  19. Actually, I forgot to answer your quesions, so here we go. Can struct contain signals that flow in different directions? Yes, of course. struct is just a a wrapper which handles datatype as one Can sc_inout<struct T> also map directly to another module with the same sc_inout<struct T>? Well, ports need to connect to signals, there is no way to connect 2 ports directly except you do a hierarchical binding Am I also setting the struct contents correctly? This I answer in the last post.
  20. The problem is that you do not write to the signal carrying the struct (and therefore you do not trigger any event). The SetValid() call implicitly triggers a read (thru the overloaded cast) but you never write back to the signal. Either you change the use of SetValid (and SetReady): { hs data = handshake.read(); SetValid(hs, false); handshake.write(data); } Here the call to wriite() trigges the respective events. The other option is to change SetValid() to take a signal reference and move the code into the function. Best regards
  21. Well, the answer is i bit more complex. The main difference is that the standart requires that during the nb_transport call no sc_wait is allowed while in b_transport it si allowed. So any implementation adhereing to the standart guarantees this. Let's first look at the non-blockig implementation. tlm_phase do not denote a phase directly rather time -points o the protocol. Actually you have to phases: request and response which are denote by 2 time points each. So the initiator can indicate a start or end of a phase of a transaction and be sure that the call is not blocked by a call to wait(). So you can model the behavior and timing of a bus transaction in a fairly granular way and do something while the transaction is on-going. You can even have 2 transactions in parallel, one being in the request while the other one is in the response phase (or even more if you have more phases defined). The transaction are pipelined. Looking at the b_transport situation is different. The target can delay the transaction by calling wait() until it is ready to respond. During that time no other transaction can be ongoing, the initiator is blocked and cannot react to it. Blocking accesses can be used if timing of the communication is not of interest/not modeled (the other scenarion is loosly timed models, but that's a different story). They are easy to implement and easy to use. Non-blocking is used if the timing of the communication needs to be modeled in more detail. E.g. this allows to model, simulate and analyse bus contention situations as it allows to attach timing to all phases of a bus transaction lile grant, address phase, data phase. I hope this sheds some light -Eyck
  22. Eyck

    using gtkwave

    Actually SystemC provided sc_trace(...) functions where you register your signals and variables for tracing. Running the simulation yields a .vcd file which you can open in gtkwave. You may have a look into https://github.com/Minres/SystemC-Components-Test/blob/master/examples/transaction_recording/scv_tr_recording_example.cpp In sc_main() you will find sc_trace_file *tf = sc_create_vcd_trace_file("my_db"); sc_trace_file *tf = sc_create_vcd_trace_file("my_db"); This opens the waveform database. At the end you have to call sc_close_vcd_trace_file(tf); to properly close the database. 'tf' is a handle to the database, if you follow the code you will see how to trace signals (or variables), Best
  23. Hi, I'm not an implementer of the reference simulator but as far as I can judge the re-throw is used to find a more specific type of exception (since sc_elab_and_sim() just uses a catch-all) and uses sc_handle_exception() to convert it into an sc_report so it can be handled by the SystemC reproting system. Actually I agree it would be better to handle it directly in sc_elab_and_sim() but this would duplicate code. A side note rgd. debugging: if you use gdb there is a command 'catch throw' which stops execution right at the point where the (original) exception is thrown. This comes pretty handy in such cases. Best regards
  24. Actually you could use some kind of a router or broadcaster between the master and the target(s). Examples of this can be found here: or here: https://git.minres.com/SystemC/SystemC-Components/src/branch/master/incl/scc/router.h where the first one may be better suited as a stand-alone example HTH
  25. Eyck

    event vs software call

    SystemC is an event based simulator as VHDL or (System)Verilog simulators are. So you would write to signals, the update their values and notify an event for that so that processes can react on them. This is described in the SystemC standard, I guess paragraph 4.2 Simulation. The downside of this that each event and the evaluation of processes being triggered by this takes time. As the processes are often fairly short this incures a significant overhead and speed impact. In TL modeling you forward the function calls via a port/export directly to the affected/addressed module/function. This way a lot of context switches can be avoided and the simulation speed is higher. But since the effect (e.g. writing a register) happens immediately care needs to be taken to not introduce feedback loops and a like which won't happen if you use signales and events. To model timing you also carry some delay time with the transaction so that the functions along the call chain and the target function can tell the initiator of the transaction how long the entire transaction took. Best is to have a look into the examples coming with TLM2.0 (now being part of the SystemC distribution), also Doulos has some explanation and examples: https://www.doulos.com/knowhow/systemc/tlm2/ Best regards