Jump to content

Accuracy of SystemC timed notification


Recommended Posts


I am running a SystemC simulation for an SoC. I have sc_module which is used to generate timed notifications.

Posting a snippet of the code

class evt_notifier : public sc_core::sc_module
   /*! Constructor
   evt_notifier(sc_core::sc_module_name name_) : sc_core::sc_module(name_)
      sensitive << event;
   /*! Destructor
   virtual ~evt_notifier() { } 
   void notifier()
      while(true) {
         // uint64_t time = get_current_time();
         // do stuff reagrding handling of time elapse notification
         // std::cout << "notifier triggered at time: " << time << " time_stamp : " << sc_core::sc_time_stamp() << std::endl;
         wait();  // static sensitivity

   // Time is the interval after which to notify
   bool register(uint64_t time)
      // add a event notification based on the recv time
      // sc_core::sc_time t(time*sc_core::sc_get_time_resolution());
      // std::cout << "evt_notifier::register called with time:" << time
      //           << " current sc time:" << sc_core::sc_time_stamp()
      //           << " scheduled time from now : " << t
      //           << std::endl;
      // something like below
      // event.notify(time)

private :
   std::list <uint64_t> notify_list_;
   sc_core::sc_event event;

Now what happens next is random, as in it happens on occasional simulation runs ( I understand no such thing as random 😉 but got no other word for it). If I issue a notification for lets say time == 60000000, I get notifier thread called at 60000001 time stamp.

register called with time:60000000 current sc time:0 s scheduled time from now : 60 us

notifier triggered at time: 60000001 time_stamp : 60000001 ps
  1. What can be the possible issue here ?
  2. Is there any profiler which I can use to check pending event notifications ?
  3. What level of accuracy for timed event is guaranteed in this case ? as I see a nominal difference of 1ps only ?

Also, trying to scale down and replicate this on a testbench level doesn't reproduces the issue.

Link to comment
Share on other sites

There is no level of accuracy as this would imply some fuzzyness. The simulation kernel follows the discrete event simulation protocol and as such it is deterministic and has exact timing. So if your event is triggered with a delay of 60us the notfier is triggered 60us later. The only thing which the standard does not guarantee is the order of invocation within delta cycles as this is an implementation detail (e.g. some simulators offer to randomize this).

I can imagine several root causes:

  • there is some uninitalized value which leads to accidental increment of the time value handed into the call of register
  • your event gets notified 1ps after the notification in register(). This effectivly cancels the first notification

Commercial tool of the well-known EDA vendors offer means to check pending notifications. The reference implementation does not have this, here you would need to hooj into the simulation kernel.


Link to comment
Share on other sites

48 minutes ago, Eyck said:
  • your event gets notified 1ps after the notification in register().

Adding some more prints here and there lead me to the issue. Basically time was getting increased in a some flow by 1 ps which resulted in that notification.


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.

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