fdoucet Posted February 2, 2018 Report Share Posted February 2, 2018 Hi all, question about sc threads and events: In a Testbench monitor, i have something like this: SC_HAS_PROCESS(Monitor); Monitor(const sc_module_name& n) : Monitor_base(n) { SC_THREAD(proc); sensitive << clk.pos(); async_reset_signal_is(as_rst_n,false); reset_signal_is(rst_n,false); } Somewhere deep in proc(), there is a wait like this: wait(some_signal.negedge_event()); During the simulation, a synchronous reset is issued while proc() is waiting on the abovee negedge_event. The reset is missed by proc(). This behavior is exhibited by both accellera and commercial simulators. I can easily re-write the code to a do-while loop and resovle the issue, but was just wondering, is this by design. Is waiting on a specific event overriding all reset specs - is this by design or could this be revisited? thanks and regards, Fred Quote Link to comment Share on other sites More sharing options...
AmeyaVS Posted February 2, 2018 Report Share Posted February 2, 2018 Hello @fdoucet, What your are trying to do here in this specific scenario is known as dynamic sensitivity. Dynamic sensitivity replaces the default sensitivity of the registered SystemC process, once the event it triggered the default sensitivity would be restored for the corresponding process. Here is a reference to the discussion before in this forum: http://forums.accellera.org/topic/1210-static-and-dynamic-sensitivity/ Hope it helps Regards, Ameya Vikram Singh maehne 1 Quote Link to comment Share on other sites More sharing options...
Philipp A Hartmann Posted February 3, 2018 Report Share Posted February 3, 2018 Hi Fred, synchronous resets are indeed not triggering the process themselves (that's why it's called "synchronous) and instead are only checked when the process is triggered through other means. Typically, this would be a trigger from the static sensitivity (clk.pos() in your case). As @AmeyaVS correctly pointed out, dynamic sensitivity replaces the triggering behavior (not the reset specs). So your synchronous reset would be checked only, when some_signal is de-asserted. Asynchronous resets continue to fire. A polling loop would be the most accurate way to model your design wrt. resets. If you know the reset signals at the point of that wait statement, you can approximate the behavior by waiting for either the signal or the reset (which will then reset the process) wait( some_signal.negedge_event() | rst_n.negedge_event() ); Of course, this might be one clock cycle off. To be correct, you need to have an event that's synchronous to the clock again: sc_event thread_rst_ev; SC_METHOD(thread_sync_reset); sensitive << clk.pos(); // ... void thread_sync_reset() { if (rst_n == false) thread_rst_ev.notify(); } // ... wait( some_signal.negedge_event() | thread_rst_ev ); By the way: a smart wait_until( some_signal == false ), which supports (synchronous) resets and avoids polling internally would be a very useful feature for writing signal-level protocols. Greetings from Duisburg, Philipp Quote Link to comment Share on other sites More sharing options...
fdoucet Posted February 6, 2018 Author Report Share Posted February 6, 2018 Hi guys, thanks for the reply. i agree wait_until is exactly what i'd need here (with support for multiple resets) Long time ago, was there a wait_until() (implemented as a do/watching) constructs that got deprecated? regards, Fred Quote Link to comment Share on other sites More sharing options...
AmeyaVS Posted March 6, 2018 Report Share Posted March 6, 2018 Hello @fdoucet, Sorry for the late response. But the "WAIT_UNTIIL()" macro has been refactored to be "SC_WAIT_UNTIL()". You can find the reference to the changes in the "RELEASENOTES" of the SystemC 2.3.2 release: RELEASENOTES:388: - The non-standard macros WAIT, WAITN and WAIT_UNTIL have been RELEASENOTES:389: renamed to SC_WAIT, SC_WAITN, SC_WAIT_UNTIL. Hope it helps. Regards, Ameya Vikram Singh Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.