thread resets and events

[fdoucet]

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

[AmeyaVS]

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

[Philipp A Hartmann]

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

[fdoucet]

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

[AmeyaVS]

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