Re: reset_event

John,

with the addition of sc_pause and the corresponding extended simulation
states SC_RUNNING, SC_PAUSED, SC_STOPPED etc, we need to define how we
map these to the old boolean sc_is_running query.

If I remember correctly, we considered to define sc_is_running to be

bool sc_is_running() {
  return sc_get_status() & ( SC_PAUSED | SC_RUNNING );
}
for backwards compatibility. If we decide this to be SC_RUNNING only,
you are right, that sc_is_running would return false during destruction.

I'm not sure, what would be the best solution here, though. I've not
seen many use cases for sc_is_running() from within sc_main(), so it may
not be a problem to go for sc_is_running() to be strictly equivalent to
SC_RUNNING.

What do others think?

Greetings from Oldenburg,
  Philipp

On 16/11/10 12:04, john.aynsley@doulos.com wrote:
>
> I have just realized that we made a sideways swerve in the middle of this
> discussion. We started with the point that sc_is_running() could not be
> guaranteed to be false when called from a destructor because sc_stop()
> might not have been called, and hence the LRM needed to change so that
> sc_is_running() could still be true in a destructor.
>
> However, we then introduced sc_pause.
>
> As I understand it, the current proposal is:
>
> sc_start(any_argument_list_you_like);
>
> sc_assert( sc_get_status() & (SC_IS_PAUSED | SC_IS_STOPPED );
> sc_assert ( sc_is_running() == false );
>
> Hence I believe the current proposal implies that sc_is_running() == false
> when called from a destructor, after all.
>
> Is that correct?

-- 
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://www.offis.de/
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.