Re: sc_pause and sc_get_status() - RESEND

Mac, All,

I'm fine with that, provided we are talking about sc_get_status()
returning a simple bit mask, 1-bit-per-stage, no clever encoding.

Cheers,

John A

From:
"Michael (Mac) McNamara" <mcnamara@cadence.com>
To:
"'john.aynsley@doulos.com'" <john.aynsley@doulos.com>,
"'philipp.hartmann@offis.de'" <philipp.hartmann@offis.de>
Cc:
"'systemc-p1666-technical@eda.org'" <systemc-p1666-technical@eda.org>
Date:
21/05/2010 15:33
Subject:
Re: sc_pause and sc_get_status() - RESEND

John, Phillip, I would much rather read:

if( sc_get_status() &
( SC_BEFORE_END_OF_ELABORATION |
SC_END_OF_ELABORATION | .
SC_START_OF_SIMULATION ) ) {

// do stuff safe in any stage of elaboration...

}

Users could predefine the bitmask and use that:
#define SC_ELABORATION (SC_BEFORE...) at their peril.

The slight advantage/danger of our defining this for them is that when/if
we later decide to divide a stage into a sub stage (prepone...), we can
add the new stage into our bitfield, and make their code work
automatically (break automatically).

Mac

From: owner-systemc-p1666-technical@eda.org
<owner-systemc-p1666-technical@eda.org>
To: Philipp A. Hartmann <philipp.hartmann@offis.de>
Cc: systemc-p1666-technical@eda.org <systemc-p1666-technical@eda.org>
Sent: Fri May 21 07:00:05 2010
Subject: 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. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.