Jump to content

thread resets and events


fdoucet

Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 4 weeks later...

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

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...