Re: sc_pause and sc_get_status() - RESEND

John,

apart from potential implementation difficulties for adding a too
flexible sc_pause() functionality, I think most of the open questions
are rather cosmetic. So for me, a bike shed of any colour will just do
fine. :-)

Some comments below.

On 20/05/10 18:33, john.aynsley@doulos.com wrote:

[snip agreed conclusions]

> I would propose sc_core::sc_get_status() returns the following

If we add this enum directly to the namespace sc_core, shouldn't the
enum values have an "SC_" prefix?

> namespace sc_core
> {
> enum sc_status { ...
>
> ELABORATION prior to the first call
> to sc_start or before_end_of_elaboration
> BEFORE_END_OF_ELABORATION within a callback of that name
> END_OF_ELABORATION within a callback of that name
> START_OF_SIMULATION within a callback of that name
> RUNNING from the evaluation or
> update phases of the scheduler
> PAUSED within sc_main after
> sc_pause has taken effect
> STOPPED within sc_main after
> sc_stop has taken effect
> END_OF_SIMULATION within a callback of that name
> (after sc_stop or, in the absence of sc_start, at the end of simulation)

Maybe we could specify the values of the enum in a way, that
SC_ELABORATION and SC_RUNNING cover multiple sub-phases?
This way, a user-query could simply be:

if( sc_get_status() & SC_ELABORATION )
  // either:
  // SC_ELABORATION (e.g. = 0x08)
  // SC_BEFORE_END_OF_ELABORATION = 0x09
  // SC_END_OF_ELABORATION = 0x0A
  // SC_START_OF_SIMULATION = 0x0C

if( sc_get_status() & SC_RUNNING ) // essentially sc_is_running()
  // either:
  // SC_RUNNING = 0x10
  // SC_PAUSED = 0x30
  // do we want to have SC_EVALUATION, SC_UPDATE ?

if( sc_get_status() & SC_STOPPED )
  // either:
  // SC_STOPPED = 0x80
  // SC_END_OF_SIMULATION = 0xC0

  The values are of course only made up off the cuff. I think, we
shouldn't specify exact values, only their bitwise relationships.
We could also define sc_status as a bit-field instead.

> Some questions:
>
> - 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?

> - Is it influenced by sc_set_stop_mode =
> SC_STOP_FINISH_DELTA/SC_STOP_IMMEDIATE?
> - or do we add an sc_set_pause_mode?
> - or do we add a PAUSE argument to sc_stop instead of adding sc_pause?

  I don't have any preference here. There is much overlap in the
semantics of sc_stop and sc_pause (e.g. concerning phases that are
executed before stopping/pausing the execution), though.

> - What should sc_is_running return when PAUSED? Tor and I were thinking
> <true>.

Yes, we definitely need this for backwards compatibility.

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.