John,
regarding the sc_status implementation, I have no strong opinion in
either direction. So I'm fine with whatever decision is made.
Regarding the behaviour of "sc_start()" vs. "sc_pause()", please see below.
On 21/05/10 16:00, john.aynsley@doulos.com wrote:
[snip]
>> - Exactly when should sc_pause take effect?
>
> It should be as similar to sc_stop() as possible, depending on the pause
> mode (immediate, finish delta).
>
> The original proposal contained a 'finish time step'. This is needed to
> avoid warping the simulation time to "infinity", as some implementations
> do on event starvation. Is this behaviour actually defined somewhere?
>
> [JA] I AGREE THE LRM SHOULD EXPLICITLY STATE SOMETHING ABOUT NOT WARPING
> TIME FOLLOWING AN EXPLICIT CALL TO sc_pause. BUT IF sc_pause IS CALLED
> IMPLICITLY FROM sc_start(void) DUE TO EVENT STARVATION, THEN time=infinity
> IS RIGHT-AND-PROPER, SO RESTARTING SIMULATION WOULD NOT SEEM TO MAKE
> SENSE. HAVE I MISSED SOMETHING?
From what I see in the current LRM, nothing is said about the value of
sc_time_stamp() after a return from 'sc_start()' due to event starvation.
4.2.1.5 merely says:
"If no pending timed notifications or time-outs exist, the end of
simulation has been reached. So, exit the scheduler."
In practice, it's sometimes rather annoying not to be able to restart
the (timed) simulation, due to a now infinite simulation time,
especially when doing co-simulation. I think, this is one of the
motivations for the proposed "finish timestep" mode of sc_pause().
I would rather prefer to have 'sc_start()' call an implicit
'sc_pause()' and thus keep the simulation time at the last valid value.
This way not only delta-cycle steps are possible after a return from
'sc_start()'.
Is there any reason (apart from implementation details) to warp the
simulation time to infinity? Why not allow to inject events from
sc_main() and let the simulation continue?
On the other hand, if we take 4.2.1.5 literally ( "...the end of
simulation has been reached..."), maybe even the 'end_of_simulation()'
callbacks should be called automatically? Of course, then no further
calls to sc_start() would be allowed (but at least this would lead to an
error, instead of more or less undefined behaviour).
Greetings from Oldenburg,
Philipp
-- Philipp A. Hartmann Hardware/Software Design Methodology Group OFFIS R&D Division Transportation | FuE-Bereich Verkehr Escherweg 2 · 26121 Oldenburg · Germany Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri May 21 08:01:22 2010
This archive was generated by hypermail 2.1.8 : Fri May 21 2010 - 08:01:23 PDT