gyro Posted March 8, 2022 Report Share Posted March 8, 2022 Hi, 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 { public: /*! Constructor */ evt_notifier(sc_core::sc_module_name name_) : sc_core::sc_module(name_) { SC_HAS_PROCESS(evt_notifier); SC_THREAD(notifier); sensitive << event; dont_initialize(); } /*! Destructor */ virtual ~evt_notifier() { } public: 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 What can be the possible issue here ? Is there any profiler which I can use to check pending event notifications ? 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. Quote Link to comment Share on other sites More sharing options...
Eyck Posted March 8, 2022 Report Share Posted March 8, 2022 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. gyro and David Black 1 1 Quote Link to comment Share on other sites More sharing options...
gyro Posted March 8, 2022 Author Report Share Posted March 8, 2022 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. -Thanks Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.