Question about expected behavior of wait event with delta cycle timeout

[Yi-Chung.Lee]

Dear all,

I am confused about the expected behavior of wait event with timeout for sc_thread when the time-out value is delta cycle (i.e. SC_ZERO_TIME).

//SC_THREAD
void recv() {
    ...
    wait(SC_ZERO_TIME, e); 
    ...
}

Given timestamp T and event e is triggered, what should be the time that recv() resumed from wait function? T or T+delta? 

I think it should be T since the event is not timeout. However, the simulation result behaves as the thread resumed at T+delta.

The following code is an example. The send function send event e @ 0 ns and the event will be triggered @ 3 ns. The recv function wait the event every 1 ns and wait delta cycle for each time. The simulation result shows that @ 3 ns, the event e is triggered but the e.triggered() is not asserted. This represents that the recv function resumed from wait function at T+delta instead of T.

Can anyone give some explanation? Thanks a lot.

SC_MODULE(test) {
  sc_event e;

  void send() {
    while(1) {
      std::cout << "send event @ " << sc_time_stamp() << std::endl;
      e.notify(3, SC_NS);
      wait(1, SC_NS);
    }   
  }

  void recv() {
    while(1) {
      wait(SC_ZERO_TIME, e); 
      if(e.triggered())
        std::cout << "recv event @ " << sc_time_stamp() << std::endl;
      else
        std::cout << "lost event @ " << sc_time_stamp() << std::endl;
      wait(1, SC_NS);
    }   
  }

  SC_CTOR(test) {
    SC_THREAD(send);
    SC_THREAD(recv);
  }
};

int sc_main(int argc, char* argv[]) {
  test h("TEST");
  sc_start(4, SC_NS);
  return 0;
}

 

send event @ 0 s
lost event @ 0 s
send event @ 1 ns
lost event @ 1 ns
send event @ 2 ns
lost event @ 2 ns
send event @ 3 ns
lost event @ 3 ns

 

[Philipp A Hartmann]

The event is triggered() between the wait(1, SC_NS) and the following wait(..., e). Therefore, you will always run into the "timeout". You can probably validate this, by adding another e.triggered() check between the two wait() calls.

[Yi-Chung.Lee]

22 hours ago, Philipp A Hartmann said:

The event is triggered() between the wait(1, SC_NS) and the following wait(..., e). Therefore, you will always run into the "timeout". You can probably validate this, by adding another e.triggered() check between the two wait() calls.

Hi Philipp,

thank you for the explanation. This do answer my question.

The mechanism seems like that when calling wait(..., e) and event e triggered occurs at the same moment (e.g. @ 3 ns in this case), the wait function would not catch the event. Therefore, timestamp moves on to 3 ns + delta due to timeout and e.triggered() is not asserted. This is what you mentioned that the event is triggered between the wait(1, SC_NS) and the following wait(..., e).

[David Black]

sc_core::wait will always move to a subsequent (i.e., different) delta cycle. 

// sc_time_stamp: 0 s sc_delta_count:0
wait( 1, SC_US );
// sc_time_stamp: 1 us sc_delta_count:1
wait( SC_ZERO_TIME );
// sc_time_stamp: 1 us sc_delta_count: 2
wait( 2, SC_NS );
// sc_time_stamp: 1002 ns sc_delta_count: 3