Re: sc_pause

Philipp, All,
 
 Good question. Part of the proposal is to change the spec of what happens on return from sc_start()  [empty argument list]  without sc_stop() having been called, that is, on event starvation. The new spec is that:
 
 * Simulation time shall remain at the time of the most recent event notification or time-out
 * After return from sc_start(), sc_get_status() == SC_PAUSED
 * sc_start() may be called again
 * [5.2.1.5] gets refined
 
 If the most recent happening is an event notification, then by definition, no processes were made runnable as a result of that notification. Simulation would resume with a new evaluation phase with simulation time = time of that notification, and delta_count incremented
 
 If the most recent happening is a time-out, then by definition, no notifications were scheduled as a result of that process running. Simulation would resume with a new evaluation phase with simulation time = time of that time-out, and delta_count incremented
 
 I think that works.
 
 John A

-----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----
To: john.aynsley@doulos.com
From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
Date: 11/12/2010 11:45PM
Cc: "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Subject: Re: sc_pause

John,

I'm fine with the semantics of sc_pause/get_status. Especially
completing the full delta cycle is a Good Thing.

Apart from the interaction with Process Control (see my separate mail),
I just have one minor question wrt to sc_start() + event starvation,
which has not been finally decided in the first discussion, I guess.

IIUIC, sc_start( SC_ZERO_TIME ) and sc_start( time ) both leave the
state of the simulation in SC_PAUSED, when returning due to sc_pause()
or by reaching the requested simulation time, right? I agree with this.

But what happens with sc_start() without any arguments and
sc_get_status()? SC_PAUSED or SC_STOPPED?

Quote the LRM (5.2.1.5 in the latest draft):

 "If no pending timed notifications or time-outs exist, the end of
  simulation has been reached. So, exit the scheduler."

What exactly should "exit the scheduler" mean here? Should it be
possible to start the scheduler again? (The PoC simulator "supports" it
for delta cycles only, which feels like a bug to me.)

If the simulation shall not be restarted, SC_PAUSED doesn't seem to make
much sense. Maybe we should return SC_STOPPED then? Should we even
call the end_of_simulation callbacks?

Opinions?

Greetings from Oldenburg,
 Philipp

On 12/11/10 14:49, john.aynsley@doulos.com wrote:
> It seems we are all set. I will write up the sc_pause/sc_get_status
> proposal in the LRM. As usual, shout if you want to raise objections.
>
> John A

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
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.