maehne
commented
4 years ago The behaviour you are describing is not a bug, but intended and specified such in IEEE Std. 1666-2011. The behaviour of end_of_simulation is specified in clause 4.4.4:
The implementation shall call member function
end_of_simulationat the point when the scheduler halts because of the functionsc_stophaving been called during simulation (see 4.5.3) or at the very end of simulation if simulation is initiated under the direct control of the kernel.
However, your application controls elaboration and simulation through sc_main and sc_start (clause 4.3). Figure 1 on page 34 is also helpful for understanding. sc_start can be called multiple times from sc_main to advance simulation under tighter control of the application enabling, e.g., applying stimuli and controlling tracing of signals.
In clause 4.3.4.2 Function sc_start, it is explicitly stated that:
Applications are recommended to call function
sc_stopbefore returning control fromsc_mainto ensure that theend_of_simulationcallbacks are called (see 4.4.4).
Therefore, it is your responsibility to call sc_stop at the end of sc_main to ensure the execution of the end_of_simulation callbacks.
I therefore conclude that this issue can be closed.
nayakche
end_of_simulation() from the name must trigger at the end of simulation. irrespetive of the way in which simulation gracefully exits. However, the observation is : 1) When sc_stop() is called, end_of_simulation callbacks are triggered. 2) When sc_start(until) is given end_of_simulation callbacks are not triggered.
I saw the below piece of code in simcontext.cpp::simulate() function : exit_time: // final simulation time update, if needed if ( t > m_curr_time && t <= until_t ) do_timestep(t);
It looks like we are not calling end() function during exit time which would trigger the end_of_simulation callbacks. Not sure if my understanding is correct.