Jump to content

Question about expected behavior of wait event with delta cycle timeout


Recommended Posts

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

 

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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

 

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.

 Share

×
×
  • Create New...