Re: sc_pause and sc_get_status() - RESEND

Philipp, All,

Comments inserted below...

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
john.aynsley@doulos.com
Cc:
systemc-p1666-technical@eda.org
Date:
20/05/2010 20:35
Subject:
Re: sc_pause and sc_get_status() - RESEND

<snip>

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

[JA] YES, AGREED.

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

<snip>

[JA] TO QUOTE 1666:
"Whether a particular action is allowed within
a particular callback cannot be inferred from the terms during elaboration
and during simulation alone but is
defined in detail in 4.4. For example, a number of actions that are
permitted during elaboration are explicitly
forbidden during the end_of_elaboration callback."

[JA] THIS IS JUST MY OPINION, BUT I WOULD PREFER THAT WE REQUIRE USERS
EXPLICITLY TO LIST THE VALUES THEY WANT FROM AN ENUM RATHER THAN USING BIT
MASKS, BECAUSE I THINK IT IS CLEARER AND MORE FOOL-PROOF.

> - 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?

John A

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.