Jump to content


Popular Content

Showing content with the highest reputation since 12/20/2018 in all areas

  1. 3 points
    The Accellera SystemC AMS Working Group released the 2020 edition of the SystemC AMS User's Guide. You will find the user's guide on this page: https://www.accellera.org/downloads/standards/systemc This version of the user's guide is fully compatible with the SystemC AMS standard released as IEEE Std. 1666.1-2016. It describes all the features introduced in the SystemC AMS language standard during the last decade. For example, the user’s guide now explains the use of the dynamic timed data flow capabilities, to make AMS system simulations even more efficient and running even faster. The SystemC AMS Working Group is currently preparing the release of the user's guide application examples as separate download. Availability of these application examples will be communicated at a later stage. Please use this forum to post your questions or remarks on the user's guide.
  2. 3 points

    TLM CPU modeling

    There is no such thing as CPU TLM modeling. Usually you write a C/C++ processor model with the needed accuracy (instruction accurate, cycle approximate, cycle accurate) and wrap it in a way that you translate memory accesses into TLM socket accesses. Along with that you need to manage to syncronization of the time of your model and the SystemC time (to run e.g. in loosly timed mode). Another task is to take the returned execution time of the bus accesses into account for the execution of the CPU model. This involves also the selection and implementation of the accesses (DMI & blocking or non-blocking). You can find a complete example of an instruction accurate VP at https://git.minres.com/DVCon2018/RISCV-VP (or https://git.minres.com/VP/RISCV-VP which is a newer version). The wrapper for the C++ model in SystemC can be found at https://git.minres.com/DVCon2018/RISCV-VP/src/branch/develop/riscv.sc/incl/sysc/core_complex.h To put it straight: doing this correctly is a non-trivial task as it is the implementation of a micro-architecture model of a CPU. One option is to build an instruction accurate ISS and add a microarchitecture model like it is done in the ESECS project (https://github.com/MIPS/esesc) BR
  3. 3 points
    SystemC 2.3.2 (and later) does support a query whether an event was triggered in the previous delta cycle (or immediately in the current evaluation cycle). This is similar to the sc_signal<>::event() function. With this, you can ask every element in your array, whether it was triggered and may have caused a wakeup of the process. Of course, multiple events can have triggered simultaneously and will only cause a single wakeup of the process. for( const auto ev& : e ) { if ( ev.triggered() ) { // ... } } Hope that helps, Philipp
  4. 2 points

    sc_clock Doubt

    sc_clock triggers itself based on the period and the (in your case default) constructor settings. The period is the default_time_unit.
  5. 2 points
    You are initailaizing fl_ptr during consturction, not during execution. In generator.hpp you have: float* fl_ptr = reinterpret_cast<float*>(dmi_mem); //ovo sam ja pisao This never updates fl_ptr to the actual value of dmi_ptr. Actually your access should look like: if (dmi_valid) { dmi_mem = dmi.get_dmi_ptr(); //dmi_mem is pointer to ram[] array in memory.h float* fl_ptr = reinterpret_cast<float*>(dmi_mem); for (int i = 0; i != 20; ++i) fl_ptr[i] = 12.7; }
  6. 2 points
    Your sc_trace function is a member function of the TraceList class and cannot be called like the sc_trace functions coming with the SystemC reference implementation. Those are free functions in the sc_core namespace. Moreover your sc_trace implementation is non-static so it cannot be used without a TraceList object. You need to move the function out of the class scope. Basically this is a valid approach to setup complex types. But under performance considerations I would suggest to use a different container. Best choices are std::vector or std::dqueue. And if you are using C++ 11 I would replace the while loop with a range based loop, something like: for(auto& val: var.lst) { // use namespace, compiler otherwise chooses wrong function sc_core::sc_trace(tf, val, nm + std::to_string(pos++)); }
  7. 2 points
    2 days! That's fast response Exactly! If you're not open in the design/pre-release phase you're likely to miss use cases and if the members have committed themselves to solutions and switched their focus to other tasks I imagine that there will be an unwillingness to go back and redo things even if new important insights have been revealed. I think most users would like a code base they can build upon, not one that needs adaptations to make it work. Being fully transparent about the code in the making will reduce the risk for such adaptations What I'm suggesting is free and efficient access to the collective intelligence of the entire community at a point in the development cycles where it makes the most difference. I'm not suggesting a shift in the rights to make the final decisions. That's exclusive to the paying members. What's preventing this from happening within Accellera?
  8. 2 points
    Please be aware, that an sc_and_event_list does not imply that the events in the list are triggered at the same time. I would suggest to keep the only the clock sensitivity and act on the triggers in the body of the method instead: SC_METHOD(func2); sensitive << clk.pos(); dont_initialize(); // ... void func2() { if( nreset.posedge() ) { // nreset went high in this clock cycle // ... } } Alternatively, you can be sensitive to nreset.pos() and check for clk.posedge() (as a consistency check), if you don't have anything else to do in the body of the method. With this approach, you might be able to avoid unnecessary triggers of the method. Side note to Eyck: There's a small typo in the example above, which should should use "&=" to append to an sc_event_and_list. ev_list &= nreset;
  9. 2 points
    Unfortunately I'm not with a member company. I was hoping that I'd have read permissions regardless of my current affiliation. As a user I'd like to see the connection between discussions in the official forum, the issues reported to the issue management system, and the code being developed in response to that. The ability to immediately test that code and possibly give feedback as code comments or a pull request. More like Github, Gitlab and other platforms. Seems to me that this would be a more efficient way to give and get user feedback.
  10. 2 points
    David Black

    Systemc performance

    Perhaps you would like to share your code for measurements via GitHub? Measuring performance can be tricky to say the least. How you compile (compiler, version, SystemC version) and what you measure can really change results. Probably helps to specify your computer's specifications (Processor, RAM, cache, OS version) too. Processor (vendor, version) L1 cache size L2 cache size L3 cache size RAM OS (name, version) Compiler (name, version) Compiler switches (--std, -O) SystemC version SystemC installation switches How time is measured and from what point (e.g. start_of_simulation to end_of_simulation) Memory consumption information if possible This will help to make meaningful statements about the measurements and allow others to reproduce/verify your results. It is also important to understand how these results should be interpreted (taken advantage of) and compared. As with respect to TLM, it will get a lot more challenging. For example, what style of coding: Loosely Timed, Approximately Timed. Are sc_clock's involved?
  11. 2 points
    David Black

    sensitivity list

    You can only specify sensitivity on objects that have events or event finders directly accessible at the time of construction. Normally this means using either a suitable channel, port or explicit event. If you wrap your int's with a channel such as sc_signal<T>, you can do it. Example - https://www.edaplayground.com/x/5vLP
  12. 2 points
    David Black

    Heartbeat, clock and negedge

    You can use it however you like. We didn't use it everywhere and I'm sure there are more areas where it might be applicable. The main point is that "Performance is a function of simulator CPU activity and how well it used." In some cases such as clocks, there is a lot of activity that goes unused. Many designs really only use the positive edge of the clock. In some designs, the activity can even be reduced significantly. Another instance is timers that often are only touched when they are set up and timeout after N clocks. The RTL approach to modeling a timer decrements the timer value on every clock. A behavioral approach would be: void set_timer( int N ) { assert( N > 0 ); delay = N * clock.period(); setup_time = sc_time_stamp(); projected_time = setup_time + delay; timeout_event.notify( delay ); } The current value of the timer can always be had with: int get_timer_value( void ) { return ( projected_time - sc_time_stamp() ) % clock.period() ); } So you really don't even need the clock in many instances. Instead replace clock.period() with a simple constant. Fast and smart SystemC models don't use sc_clock at all.
  13. 2 points
    The issue is likely caused because you access a port (via -> or for example calling functions like .read()) already inside the module constructor. You should only access ports after binding has completed, this means from within a SystemC process or in end_of_elaboration() / start_of_simulation() callbacks. Hope that helps, Philipp
  14. 2 points
    This means that a port is not bound to an interface. A port is just a kind of a forwarder of an interface. So if none is bound nothing can be forwarded. E.g. if you have a sc_in<bool> it forwards the sc_signal_in_if which allows you to read and wait for events. But there needs to be 'something on the other side' which is usually a signal (implementing the sc_signal_in_if) being bound to the socker. But without further information it is hard to provide more help. Best regards
  15. 2 points
    Thanks! I can reproduce the behavior and verified that removing the dynamic sensitivity in sc_thread_process::kill_process fixes the issue: void sc_thread_process::kill_process(sc_descendant_inclusion_info descendants ) { // ... if ( sc_is_running() && m_has_stack ) { m_throw_status = THROW_KILL; m_wait_cycle_n = 0; remove_dynamic_events(); // <-- add this line to avoid the exception simcontext()->preempt_with(this); } // ... } I'm not sure, if it is necessary to do the same for the static sensitivity. At least I haven't come up with a similar scenario, where the error is actually "incorrect".
  16. 2 points
    Actually, you can start a sequence in any phase. It is more important to understand the domain/scheduling relationships between the task based (i.e. runtime) phases. UVM undergoes a number of pre-simulation phases (build, connect, end_of_elaboration, start_of_simulation) that are all implemented with functions. Once those are completed, the task based phases begin. The standard includes two schedules. One is simply the run_phase, which starts executing at time zero and continues until all components have dropped their objections within the run_phase. The other schedule contains twelve phases that execute parallel to the run phase. They are: pre_reset, reset, post_reset, pre_config, config, post_config, pre_main, main, post_main, pre_shutdown, shutdown, and post_shutdown. They execute in sequence. Every component has the opportunity to define or not define tasks to execute these phases. A phase starts only when all components in the previous phase have dropped their objections. A phase continues to execute until all components have dropped their objections in the current phase. Many companies use the run_phase for everything because there are some interesting issues to consider when crossing phase boundaries. In some respects it may be easier to use uvm_barriers for synchronization. Drivers and monitors (things that touch the hardware) are usally run exclusively in the run_phase, but there is nothing to prevent them also having reset_phase, main_phase, etc...
  17. 1 point
    AFAICS you don't increment the index i in the while loop. But your code is way to complex.: std::ifstream ifs("TEXT.txt"); if(ifs.is_open()){ int buf = 0; for (int i = 0; i < MEM_DEPTH; i++) { ifs >> buf; buff_1[i]=buf } } ifs.close(); should replace everything from fopen() until fclose(). And you should avoid using macros, they will bite you. '#define MEM_DEPTH 20' should become 'const size_t MEM_DEPTH=20;'.
  18. 1 point
    You dot need a reference to the covergroup class. You can omit this line of code: cg_fsm_state cg_fsm_state_inst; In the constructor you are calling new directly on the coverage class name: cg_fsm_state = new();
  19. 1 point
    Hello @mo_ayman, Well you could get it early for review comments from the people in SystemC LWG. Plus people with similar setup to yours can also take a jab at it in getting it fixed. Regards, Ameya Vikram Singh
  20. 1 point
    I suggest to move to SystemC 2.3.3, if possible. (The error message indicates, that you seem to be using SystemC 2.3.1). Secondly, can you show the derived class of the fifo as well (including its constructor)?
  21. 1 point
    The SystemC AMS standard defines in section (sca_util::sca_trace) that it can trace objects of type sca_traceable_object. Since all ELN primitives are derived of this type, you can simply trace the ELN component itself, see example below SC_MODULE(eln_circuit) { // node declaration sca_eln::sca_node n1; // ELN node sca_eln::sca_node_ref gnd; // ELN ground // component declaration sca_eln::sca_vsource vin; sca_eln::sca_r r1; // constructor including ELN netlist eln_circuit( sc_core::sc_module_name nm ) : vin("vin", 0.0, 1.23), r1("r1", 1e3) { // Only ELN primitives requires explicit timestep assignment to one element vin.set_timestep(1.0, sc_core::SC_MS); // netlist vin.p(n1); vin.n(gnd); r1.p(n1); r1.n(gnd); } }; int sc_main(int argc, char* argv[]) { eln_circuit cir("eln_circuit"); sca_util::sca_trace_file* tf = sca_util::sca_create_tabular_trace_file("trace.dat"); sca_util::sca_trace(tf, cir.n1, "v_n1"); sca_util::sca_trace(tf, cir.vin, "i_through_vin"); sca_util::sca_trace(tf, cir.r1, "i_through_r1"); sc_core::sc_start(1.0, sc_core::SC_MS); sca_util::sca_close_tabular_trace_file(tf); return 0; }
  22. 1 point
    Timur Kelin

    Implement sc_trace for std::string

    The basic idea: calculate hash for the string call sc_trace for the hash value update a translation file which maps hash values and the string contents. Exemplar github project which utilizes this approach: https://github.com/timurkelin/simschd In this project the translation file is written before the simulation starts raw 64-bit hash values: simvision mmap translation applied: simvision mmap is generated automatically and translates string hash (%x=) into string value (-label {}). mmap new -reuse -name schd -radix %x -contents { {%x=0000000000000000 -label { } -bgcolor #000000 -font -*-courier-medium-i-normal--12-* -shape z -textcolor #F8F8FF -linecolor green} {%x=613d30040ed92e78 -label {delay_chain.dly10} -bgcolor #000000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green} {%x=d1a020f2dd73715f -label {delay_chain.dly10} -bgcolor #000000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green} {%x=69071983ebd1b6d4 -label {delay_chain.dly10} -bgcolor #000000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green} {%x=3a5413510c68f021 -label {run_80.exec_80()} -bgcolor #808000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green} {%x=55691ef70e86d835 -label {run_60.exec_60()} -bgcolor #8b0000 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green} {%x=6f9e19f9823cb15c -label {run_40.exec_40()} -bgcolor #4b0082 -font -*-courier-medium-i-normal--12-* -shape bus -textcolor #F8F8FF -linecolor green} } generated gtkwave translation file for the similar appearance 0000000000000000 ?grey0? 613d30040ed92e78 ?grey0?delay_chain.dly10 d1a020f2dd73715f ?grey0?delay_chain.dly10 69071983ebd1b6d4 ?grey0?delay_chain.dly10 3a5413510c68f021 ?OliveDrab?run_80.exec_80() 55691ef70e86d835 ?DarkRed?run_60.exec_60() 6f9e19f9823cb15c ?navy blue?run_40.exec_40()
  23. 1 point
    Since you are talking about timing I would stick to a more AT like modeling style using the non-blocking transport functions. In this case you should use a memory manager (see section 14.5 of the IEEE standard). For this you need to implement the tlm::tlm_mm_interface (there a few implementations out there, you may google them). The mechanism works similar to a C++ shared pointer. The initiator always pulls a new transaction from the memeory manager and sends via its socket. Each component dealing with the transaction calls acquire() on the payload and release() once it is finished with it. Upon the last release() call the transaction is automatically returned to the memory manager and can be reused. HTH
  24. 1 point
    You cannot have a delay in end_of_elaboration() or start_of_simulation() since those are callback functions outside of the (timed) simulation cycle. One thing you could do is to start the gdb within a SC_THREAD where you have a wait(SC_ZERO_TIME) to let the updates settle: void start_gdb_thread(){ wait(SC_ZERO_TIME); start_my_gdb(); } BR
  25. 1 point
    You specified a signed number which was converted to unsigned under rules of twos complement. Change “0x to “0xus and you will obtain desired results. See section 7.3 String literals on page 199 of IEEE-1666-2011 for more information.
  26. 1 point

    sc_fifo.read() does not work

    SC_MODULE(DF_Fork){ sc_fifo_in<int> input; sc_fifo_out<int> output1,output2; void process(){ while(1){ int value = input.read(); output1.write(value); //output1.write(value); output2.write(value); } } SC_CTOR(DF_Fork) {SC_THREAD(process);} }; You never write on output2. Your printer then remains at value = input.read(); since it waits till data is available. Thus the simulation has nothing to do and stops itself. You can read about sc_fifo methods here: http://www.asic-world.com/systemc/channels4.html
  27. 1 point
    I see at least 1 bug in code sample: for (auto val : var.read()) here you create copies of vector elements on a stack of your function. And then pass references to them into SystemC kernel. So those will be dangling references one you return from your sc_trace overload. Change to: for (auto & val : var.read())
  28. 1 point
    Looks like XY problem to me. If you need pointer to event, use pointer.
  29. 1 point
    Roman Popov

    sc_fifo data_read_event

    Did you probably forget to add wait() into consumer thread to suspend it after first read?
  30. 1 point
    No, if you want to keep all ports in same scope you will need to follow Philipp's suggestion.
  31. 1 point
    In general avoid using multiple inheritance for aggregation. It is possible, but has many drawbacks and no major benefits. Now I regret that I've written original post, but at that time I had no enough experience myself. Now, if we read any object oriented design book, we will learn that inheritance usually means "is-a" relation ship, and "has-a" relation ship is expressed by composition. Translating into HW modeling : what we want to express is that "some_module has port bundles", and not "some_module is port bundles". We can still use single inheritance in limited cases, for example if all modules in design have clock and reset, we can have a common base class like class clocked_module : public sc_module Back to your example. I recommend to convert your port bundles into modules: struct if_inputs : sc_module { sc_inout<sc_uint<4>> SC_NAMED(R_OP_MODE); sc_inout<sc_uint<8>> SC_NAMED(R_PRESET_MANUAL); if_inputs(sc_module_name){} }; struct if_outputs : sc_module { sc_inout<sc_uint<2>> SC_NAMED(T_BIT); sc_inout<sc_uint<4>> SC_NAMED(T_OP_MODE); sc_inout<sc_uint<8>> SC_NAMED(T_PRESET_MANUAL); if_outputs(sc_module_name){} }; And now you can aggregate any number of them inside monitor. Even have a vector of port bundles: class monitor : public sc_module { public: if_inputs SC_NAMED(sim_inputs); if_outputs SC_NAMED(sim_outputs); if_inputs SC_NAMED(stub_inputs); if_outputs SC_NAMED(stub_outputs); sc_vector<if_inputs> SC_NAMED(inputs_vector, 3); monitor(sc_module_name name_); private : // implementation details };
  32. 1 point
    You have multiple instances of the "bundles" in your monitor class: inherited directly as additional members in the nested classes sim and stub To avoid the name clashes, you can make sim and stub modules themselves via: struct sim : sc_module , if_inputs, if_outputs { SC_CTOR(sim) {} } sim { "sim" };
  33. 1 point
    You have controversial requirements: a) put stored value when enable == 1 , which sounds like a dff with output_enable b) put input to output when enable == 1, which sounds more like a latch Anyway, in both cases you will need to make process sensitive to enable signal. And usually such low-level logic is modeled with SC_METHODs. In SystemC context "register" usually means some memory-mapped CSR on TLM bus 🙂
  34. 1 point
    The Accellera UVM Working Group has released the UVM 2017 0.9 reference implementation. This implementation is available as a SystemVerilog class library and is fully compatible with the IEEE 1800.2-2017 standard as defined in the Language Reference Manual. The library can be downloaded for free here. The IEEE 1800.2-2017 standard is available free of charge from the IEEE Get program, courtesy of Accellera. We encourage you to use this forum to provide feedback, ask questions, and engage in discussions.
  35. 1 point
    You would want to use an sc_event_and_list. See IEEE1666 section 5.8. As its intended use is with next_trigger() and wait() you would need to move the sensitivity into your method. So the constructor part becomes SC_METHOD(func2); and func2 should something like (snippet of your module): sc_core::sc_event_and_list ev_list; void end_of_elaboration(){ ev_list |= clk.posedge_event(); ev_list |= nreset; } void func2(){ next_trigger(ev_list); // your code here ... }
  36. 1 point

    UVM Library Test Suite and Git Repository

    The github repositories are the actively developed code for Accellera’s reference implementation (sourceforge was made read-only when github was spun up). That being said, github stores the active development for the reference implementation, not for the standard itself. The class reference (ie. The “Standard”), as well as the Accellera Reference Implementation are officially published on accellera.org: The UVM 1.2 Standard: http://accellera.org/images/downloads/standards/uvm/UVM_Class_Reference_Manual_1.2.pdf The UVM 1.2 Reference Implementation: http://accellera.org/images/downloads/standards/uvm/uvm-1.2.tar.gz
  37. 1 point
    Vegh, Janos

    Systemc performance

    I'll surely do, but this was the first verified (by me) measurement. And, I wanted to know if it can be interesting for this audience. I will clean up the code and upload in the coming days. Although the absolute values of the data are not so meaningful, even I did the measurements in debug mode.
  38. 1 point

    timer with systemC

    If you run a simulation until a certain point it time the kernel stops before evaluating the processes at this time point. So if you schedule an event for lets say 100ns and simulate for 100ns then the process being sensitive to this event will not be executed (yet). So this is intended behavior. BR
  39. 1 point
    Are you only looking at disabling process_output from getting triggered when reset is on? In that case, it is as simple as: void fir::process_output() { if (reset.read() == 0) { //reset sequence next_trigger(reset.pos()); } else if (clk.read() == 0) { //Ignore the trigger just after reset is de-asserted and //sync to next clock edge next_trigger(clk.pos()); // Note: will work even if we comment out line above, due to static sensitivity } else { if(enable.read()) { //normal operation } } } But this may not really get you a significant improvement in itself. You may want to check what is going on in "normal operation" - and see if you can optimize that.
  40. 1 point
    Unfortunately, there is currently no way to obtain the name of the affected signals/variables in this message. You can suppress the warning via: sc_core::sc_report_handler::set_actions(sc_core::SC_ID_TRACING_VCD_DUPLICATE_TIME_, sc_core::SC_DO_NOTHING);
  41. 1 point

    why is,what is, and how is tlm used ?

    Well, in TLM1.0 there is even a tlm::tlm_fifo channel which provides something similar what you use. The sockets defined in TLM2.0 are more geared towards memory-mapped busses and provide facilities to model for speed (DMI, loosly-timed blocking interfaces) or accurracy (approximately-timed non-blocking interfaces). To achive this with pure SystemC provided classes takes some effort and it ends to be proprietary... BR -Eyck
  42. 1 point

    TLM extension

    Actually this is done in the desrtuctor of the tlm_generic_payload. This part calls for all extensions the free() function. So if out is handled properly destroyed all extensions are destroyed as well. The other option is to call free_all_extensions() explicitly which also calls free() for all extensions as well as for auto extensions (those might be registered when a memory manager for the generic payload is used, usually in AT style modelling using the non-blocking interfaces). HTH
  43. 1 point

    sc_uint and unsigned int

    unsigned int has always the length defined by the underlying platform while sc_uint<> lets you specify the exact bit with of the type. In your case case I would use 'unsigned int' as it is faster and has less overhead. Best regards
  44. 1 point
    I think there are a few more options, but first, you need to acutely aware of the issue of OS thread safety. The SystemC kernel is not generally thread-safe unless you use async_request_update(), and a queue. I've done this several times. That said you have several options: Place software inside a SystemC SC_THREAD and provide convenience methods to initiate TLM transport calls. This is the simplest SystemC approach, but does not allow for modeling the actual CPU planned to be used and hence timing is not very accurate. This has the fastest performance from the SystemC point of view. Place the software on a development board that has the target CPU and some type of communications to the machine where you will run SystemC. I generally use TCP/IP sockets. Replace the driver with a special socket call passing packets to to a remote machine and receiving back the response. On the SystemC side, create an OS thread to receive the socket and inject the message into SystemC via the async_request_update call and an unbounded STL queue or FIFO of some type. A TLM 1.0 FIFO might do. A receiving thread can then pass the data into the SystemC simulation and return the result. This is somewhat more overhead, but allows for a more accurate target CPU. Obtain an ISS (Instruction Set Simulator) for the target processor and interface it to SystemC. This varies in complexity. You might look at existing models or talk with vendors such as Cadence or Mentor. Or perhaps your CPU vendor (e.g. Arm has some very nice models). As @Eyck suggested QEMU, DBT-RISE-RISCV. Also Gem5 (Google it).
  45. 1 point
    Minimal example of the actual underlying issues posted here: http://forums.accellera.org/topic/6232-killing-a-process-with-an-included-sc_event_andor_list/
  46. 1 point

    UVM Library Test Suite and Git Repository

    Thanks David. It sounds like no such tests are available. Open source projects in general are not always good at providing their test suites but I find it a bit odd that on open source library for verification doesn't provide the test suites showing how the library itself is verified. It would be easier for people to suggest improvements if they can verify whether or not such a modification breaks something else.
  47. 1 point
    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
  48. 1 point

    TLM transaction tracing

    Maybe a little bit late but there are socket implementations available which do trace tlm transactions int a SCV database. They can be found at https://github.com/Minres/SystemC-Components/tree/master/incl/scv4tlm and are used e.g. at https://github.com/Minres/SystemC-Components/blob/5f7387ab7e3dfc2ff6a7cac6fbe834ed7ec8ae36/incl/sysc/tlmtarget.h which in turn serve as building blocks in https://github.com/Minres/SystemC-Components-Test/tree/master/examples/simple_system The setup given by Kai is put into sysc::tracer where all the tracing setup (VCD & SCV) is impelemted. Best regards -Eyck
  49. 1 point
    @daveW you can tryout the SystemC 2.3.2 draft release which fixes most of the issues while building under C++11/C++14 compilers. Have a look here: Regards, Ameya Vikram Singh
  50. 1 point
    While traversing, you should have realised already, that all ports (and the other SystemC objects) are derived from sc_object. But even more specifically, you can use a pointer to sc_port_base, the non-templated base class of all ports. That said, the port_wrapper you've shown won't work as is. You'd need to do proper type erasure. But even with that, you still need to instantiate the correctly templated ports/channels within your testbench. The step from a configuration file, i.e. some runtime data, to a (statically typed) C++ object then requires some kind of factory. hth, Philipp
  • Create New...