Enhancement: ability to find last time an event triggered

[0-issue]

At times, a process that is currently sensitive (i.e blocked) on some event wants to know if/when other auxillary events might have triggered in past when it gets woken up by the blocking event. The check might even be conditional (i.e not always done on wakeup), and buried in some if/else block.

There are many approaches to change code and get such information, but each with downsides:

1. One can start adding such auxiliary events to process's sensitivity list, and complicate the process. Going this route makes code not self-documenting, as one cannot look at sensitivity list at a given line and make sense what is a process actually waiting for next.

2. One can code auxillary process/es that block on such auxillary event/s and record every time they triggered. Going this route leads to code bloat. Additionally, if the such processes are added in multiple modules on same events, it adds to run time of simulation. Such design can lead to incoherent view of last triggered time if the event happened in the same delta as a consumer process wanting to read updated last triggered time, as the process that is responsible for updating it could run after the consumer. Also, I am not sure how sim context would play in to all of this as an event can have different last triggered time in different contexts.

So, a method to get last time an event triggered would be a good addition to the event interface. It would return a time in past or the current time if the event triggered in same or previous simulation time deltas. The one corner case is when the event has never occurred, and I guess there isn't a negative value you can return. Not sure if simulation can enter max simulation time FFF....F value, if not then maybe that can be used. It might have to be a mix of logic of an internally tracked private member sc_time and sc_time::has_value(). Or the standard could consider reserving sc_time::value_type's FFF...F or such a max range for such cases. I highly doubt that any simulation would run for so long. Thanks!

Implementation point: If there isn't already an internal mechanism that runs for each event when it triggers (at trigger time), then your implementation might require adding code to both notify(...) and cancel(...). Is there a piece of internal logic that runs every event on it's trigger time? If yes, then this change would require just adding a statement that updates triggered time there.

[markfoodyburton]

I see the need for something like this, but in the past I've always been able to 'roll my own' mechanism (1 or 2). Are you planning to propose a patch?

[lmailletcontoz]

Thanks for the submission. Could you share an implementation through a Pull request and a benchmark to evaluate the overhead?