Jump to content

Leaderboard


Popular Content

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

  1. 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
  2. 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.
  3. 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
  4. 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
  5. 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".
  6. 1 point
    You cannot not check typeid() against a string as this is compiler dependend. What you shoudl do is void write_out{ if(typeid(T) == typeid(sc_dt::sc_logic){ out.write(SC_LOGIC_Z); }else{ out.write(0); } } } But actually this is more a C++ related question, in my experience Stackoverflow is a good source of help. Cheers
  7. 1 point
    Eyck

    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
  8. 1 point
    thielges

    Functional coverage- VCS

    Hi vaibhav0901 - The best way to get answers to questions specifically about VCS is to either open a new support case via Synopsys Solvnet (https://solvnet.synopsys.com) or contact your local Synopsys Applications Engineer. The short answer to your question is to use either the -cm_name or -cm_dir arguments on the simv command line to write vdb data to unique locations. -cm_dir can create an entirely new vdb directory for the test's coverage results. -cm_name creates a new section within an existing vdb. When using -cm_name it is advisable to also use -cm_test, like this: simv -cm line+cond+fsm -cm_name my_test -cm_test my_test +UVM_TESTNAME=my_test # writes coverage data to the compile-time vdb under location "my_test" regards, Bart
  9. 1 point
    David Black

    Functional coverage- VCS

    This is a tools issue and not a UVM topic per se. This forum focuses on UVM issues. Your problem probably needs to be discussed on a Synopsys forum (not Accellera). That said, I believe vcs writes to log and database files located in the same directory where the tool was launched. So you should create separate directories for each run. This will likely require some simple (not necessarily trivial) scripting automation. vcs may also have some switches to help redirect file outputs. I recommend RTFM at a minimum.
  10. 1 point
    David Black

    Temporal Decoupling

    I believe it would be fair to say that there are no universally accepted best practices, and the system design will dictate much of the implementation. In the case of shared memory, the target would need to have some idea that the memory of interest is shared. So you would need somewhere in the system to have a mapping. It might be the entire device, or a memory map might exist as a configurable object. When the target receives a read request for shared memory, it would then synchronize in order to be certain that any writes from the past are completed in other initiators. Depending on your design, you might be able to reduce the number of synchronizations if you can know apriori the nature of the sharing. E.g. if a block of memory was shared using a mutex, then synchronization might be limited to the mutex with the assumption that if you own the mutex, then the block is not written to by other initiators. This of course has some risks in the face of software defects.
  11. 1 point
    Port requires a pointer towards the object containing implementations of methods specified in the interface. Export provides the very pointer that port needs. Port goes from caller towards callee. Export goes from callee towards caller. Pseudo-graphically: // +----------------------------------------------------------------------------------+ // |struct Top : sc_module { | // | | // | initiator.p1.bind( target.x1 ); | // | | // | Initiator initiator{"orgin"}; Target target{"target"}; | // | +------------------------------------+ +--------------------------------------+ | // | |struct Initiator : sc_module { | |struct Target : sc_module { | | // | | | | | | // | | sc_port<IF> p1{"p1"}; | | sc_export<IF> x1{"x1"}; | | // | | caller.p0.bind( p1 ); | | x1.bind( callee.x0 ); | | // | | | | | | // | | Caller caller{"caller"}; | | Callee callee{"callee"}; | | // | | +----------------------------+ | | +------------------------------+ | | // | | |struct Caller : sc_module { | | | |struct Callee : sc_module, IF | | | // | | | | | | | | | | // | | | sc_port<IF> p0{"p0"}; | | | | sc_export<IF> x0{"x0"}; | | | // | | | SC_THREAD(thread1); | | | | Data m_data; | | | // | | | | | | | x0.bind(*this); | | | // | | | | | | | | | | // | | | .------------------. | | | | .----------------------. | | | // | | | | void thread1() | | | | | | void xfer( data& d ) | | | | // | | | | { | | | | | | { | | | | // | | | | p0->xfer( v ); | [p0]->[p1]->[x1]->[x0] | // Save/load d | | | | // | | | | } | | | | | | auto t = d; | | | | // | | | | | | | | | | d = m_data; | | | | // | | | | | | | | | | // Transform t | | | | // | | | | | | | | | | m_data = t; | | | | // | | | | | | | | | | } | | | | // | | | '------------------' | | | | '----------------------' | | | // | | | | | | | | | | // | | |}; | | | | | | | // | | +----------------------------+ | | +------------------------------+ | | // | | | | | | // | |}; | |}; | | // | +------------------------------------+ +--------------------------------------+ | // | | // |}; | // +----------------------------------------------------------------------------------+
  12. 1 point
    Hi Maxim, After reading some SCV documentation, it looks like we're not allowed to use smart pointers in your preferred way. E.g. we need to use "addr()" (without specific member functions like "range(int, int)") as a basis for building the expression we are using in a later stage. In your case, a practical solution would be to have no constraint on the generated address but to mask the 2 LSB after generation. -- greetz, Bas
  13. 1 point
    Simple answer: there really is no straightforward way to do this. Of course if you wanted to get into the internals of the SystemC implementation, it is possible; however, that completely violates the standard. As to why this is not allowed: performance. The desire to have efficiency overrides the desire for corner cases such as yours. How can you work around this? Several possible approaches, but here one I would use: Create a new event class that adds tracking and an API to access it. This is easy to do if you know your C++ and SystemC well enough. Trivial outline of concept:: static const sc_core::sc_process_handle NONEXISTANT; struct Tracked_Event { void notify( void ); // sets m_process_handle and notifies m_event void notify( sc_core::sc_time delay ); // same except waits for delay sc_process_handle get_trigger( void ) { return m_process_handle; } void clear( void ) { m_process_handle = NONEXISTANT; }; private: sc_core::sc_event m_event; sc_core::sc_processhandle m_process_handle; }; struct Event_array { Event_array( int depth ); void wait( void ); // clears all m_process on entry, then waits for an m_event Tracked_event operator[]( int ); sc_vector<sc_core::sc_process_handle> get_trigger_list( void ); private: sc_vector<Tracked_Event> m_event_array; sc_core::uint64 m_delta_count; };
  14. 1 point
    In reference to http://forums.accellera.org/topic/6218-wait-is-not-allowed-inside-run_phase/ I created a small demo which exhibits the same behaviour: create a process which waits on an event list which resides on its stack (and waits there forever) create a second process which, shortly after starting the simulation, will kill() the other process. This creates the following fatal message: This begs the question if this is intended behaviour or is some kind of bug: I guess in principle it should be possible to kill() a thread which is waiting on an event list. But if the event list object resides on its stack the above message is printed. If the objects is e.g. an object member, the simulation runs without error. Demo source: #include <systemc.h> SC_MODULE(top) { public: sc_event e; void thread_1() { wait(1,SC_NS); // be sure that thread_2 is already waiting t2_hdl.kill(); } void thread_2() { sc_event_or_list terminated_events; terminated_events |= e; sc_core::wait(terminated_events); // will never finish } SC_CTOR(top) { SC_THREAD(thread_1); SC_THREAD(thread_2); t2_hdl = sc_get_current_process_handle(); } sc_process_handle t2_hdl; }; int sc_main(int argc, char **argv) { top i_top("top"); sc_start(); return 0; }
  15. 1 point
    tjd

    tlm_fifo nb_peek

    Just generated one. There is a tarball attached that contains a producer, consumer, and a main that connects the two. Also included is a simple bash script with my compilation commands and the log generated from running the script where I've also appended the G++ version to it. tlm_ex.tar
  16. 1 point
    kirloy369

    Verifying Verification Components

    maybe uvm_report_catcher is what you need http://www.vlsiencyclopedia.com/2016/10/build-smart-tests-using-uvm-report-catcher.html
  17. 1 point
    Hi Kevin, you are missing the raising and dropping of an objection in the run_phase method (which would be required in SystemVerilog too) to prevent the early finish of the test sequence: void run_phase(uvm::uvm_phase& phase) { phase.raise_objection(this); [...] phase.drop_objection(this); } By adding this I get the desired result: UVM_INFO @ 0 s: reporter [RNTST] Running test ... run: before fork/join Current time is 0 s =========== fun1======== Current time is 0 s =========== fun2======== Current time is 20 ns run: after fork/join Current time is 60 ns UVM_INFO ../../../../uvm-systemc-1.0-beta2/src/uvmsc/report/uvm_default_report_server.cpp(666) @ 60 ns: reporter [UVM/REPORT/SERVER] --- UVM Report Summary --- ** Report counts by severity UVM_INFO : 1 UVM_WARNING : 0 UVM_ERROR : 0 UVM_FATAL : 0 ** Report counts by id [RNTST] 1 UVM_INFO @ 60 ns: reporter [FINISH] UVM-SystemC phasing completed; simulation finished
  18. 1 point
    Hi Bhargav, In the 1685-2014 version, component wire ports can be multidimensional, i.e., it can have muliple arrays and multiple vectors. For this reason, a portReference must support multiple dimensions as well. This is done using the partSelect element. The partSelect element can contain a single range with left and right to support a single vector as before. Or it can contain can indices plus a range. The indices indicate which dimension the range applies to. If the indices contain more than one index then the first indices apply to the arrays and the last indices apply to the vectors. Best regards, Erwin
  19. 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
  20. 1 point
    To answer the question of a fifo multiple writers and one reader, I would suggest either of two approaches: Create a module with a vector of inputs (1 per writer) and the sc_fifo output. A simple method process can then arbitrate and facilitate placing incoming data onto the output. This has the advantage of allowing a custom arbitration scheme Create an internal std::queue and limit access with a mutex (sc_mutex might work). Since the queue doesn't have a limitation, it will be up to you to manage maximum depth issues. Downside is that arbitration is managed by the mutex and may not be ideal. For a fifo with multiple readers, you probably need a manager to decide arbitrate requests, which is similar to 1 above.
  21. 1 point
    David Black

    simple socket

    I would suggest that those for-loops need a better bound and should be coded: sc_assert( objA->initiator_socket.size() >= objB->target_socket.size() && objB->target_socket.size() > 0 ); for( int i=0;i<objA->initiator_socket.size(); ++i ) { objA->initiator_socket[i].bind(objB->target_socket[i]); } Coding rule: NEVER use a literal constant when a reasonable alternative is possible. Even when "in a hurry", you will not be disappointed if you use this rule.
  22. 1 point
    David Black

    approximately timed

    IEEE 1666-2011 section 10.2 states: IEEE 1666-2011 section 10.3.4 states:
  23. 1 point
    apfitch

    user defined data type signal assignment

    How do you know the assignment is not working? When are you printing out the assigned value? Remember that you must wait at least a delta for a primitive channel to update. There's more about user defined types and sc_signal here http://www.doulos.com/knowhow/systemc/faq/#q1 regards Alan
  24. 1 point
    David Long

    static and dynamic sensitivity

    Hi Amit, A process has static sensitivity if it contains one or more calls to wait(). The sensitivity is set before the simulation starts running, usually be using "sensitive" in its parent module's constructor. Dynamic sensitivity is where a process contains one or more calls to wait(a_time_value) or wait(a_named_event). It is dynamic because the conditions that cause a thread process to wake up change as each wait statement is executed when the simulation runs. Here is a very brief example (not tested): SC_MODULE(mod) { sc_in<bool> clk; sc_event e; void proc1() { wait(); //static sensitivity e.notify(); } void proc2() { while(1) { wait(e); //wait for event (dynamic) //do something wait(1,SC_NS); //wait for time (dynamic) //do something } SC_CTOR(mod) { SC_METHOD(proc1); sensitive << clk.pos(); //static sensitivity SC_THREAD(proc2); //no static sensitivity, runs during initialization until 1st wait reached } }; You can find further details in section 4.2 of the SystemC LRM (1066.2011). Regards, Dave
  25. 1 point
    apfitch

    loosely timed vs accurate timed ??

    In a loosely timed model you only have two timing points - start of transaction, end of transaction. In an approximately timed model using the base protocol, you have four timing points - start request, end request, start response, end response - hence you can model overlapped (pipelined) transactions, because you can start a new request before you have the response to the previous request. In my example above, you would only be able to send a new transaction every 75 ns using loosely timed, so the model of the timing of the transaction is less accurate - in the loosely timed model I can send a new transaction every 75 ns, in approximately timed every 50 ns using that example. If you do not use overlapped transactions, then you could just use begin request and end response, so as you say the non-blocking (approximately timed) and blocking (loosely timed) models would give the same results, regards Alan
×