RE: sc_pause

From: Jerome CORNET <jerome.cornet@st.com>
Date: Tue Nov 23 2010 - 07:25:52 PST

Agreed with Philipp, and generally in agreement with the proposal to
have the simulation be equal to the time of the most recent event or timeout
when the simulation stops/pauses because of starvation.

Regards,

Jerome

-----Original Message-----
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Philipp A. Hartmann
Sent: Monday, November 22, 2010 6:30 PM
To: john.aynsley@doulos.com
Cc: systemc-p1666-technical@eda.org
Subject: Re: sc_pause

John,

I concur with this proposal.
Just a minor remark (my email is flaky today, sorry).

On 22/11/10 18:05, john.aynsley@doulos.com wrote:
[snip]
> We add a recommendation that an application should call sc_stop() from
> sc_main() at the end of simulation, e.g.
> if (sc_get_status() && SC_PAUSED) {

This should probably be a bitwise AND operator.

> SC_REPORT_WARNING(MSGID, "Simulation stopped running from SC_PAUSED");
> sc_stop();
> }

  Within sc_main(), sc_get_status() usually equals SC_PAUSED, right?
Only when returning via an sc_stop (or an error?) within the model,
sc_start would not leave the simulation status in SC_PAUSED.

  I agree, that explicitly calling sc_stop() is good practice before
leaving sc_main(), but a warning seems to indicate an
unwanted/unexpected situation. Maybe, this should be changed to

if( !( sc_get_status() & ( SC_STOPPED | SC_END_OF_SIMULATION ) ) ) {
   SC_REPORT_INFO(MSGID, "Simulation stopped ");
   sc_stop();
}

Greetings from Oldenburg,
  Philipp

[snip]

-- 
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 · http://offis.de/en/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
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.
Received on Tue Nov 23 07:26:55 2010

This archive was generated by hypermail 2.1.8 : Tue Nov 23 2010 - 07:26:59 PST