Re: sc_is_running

All,

  instead of adding sc_is_paused and having to consider all different
combinations, wouldn't it make sense to add a new functionality for sth.
like sc_sim_status? This way, the user could more easily identify the
correct state of the scheduler.

I've attached a small PoC implementation for such a feature (always
returning PAUSED for simplicity) based on a small wrapper around an enum
with the following states:

class sc_sim_status
{
  // ...
  enum status
  {
    NOT_STARTED = 0,
    RUNNING = 1,
    PAUSED = 2,
    STOPPED = 4
  };
  // ...
};

With this, you can do things like:

// backwards compatibility
sc_assert( sc_is_running() == sc_sim_status().to_bool() )

if( sc_sim_status() == sc_sim_status::PAUSED )
  // ...

  Of course, we could add a global function: sc_get_status()
which directly returns global enum values like SC_PAUSED and have
sc_is_running for backwards compatibility to return true, iff the
simulation has been started and is not yet stopped via sc_stop().

Regarding the different return values, these could be (which covers
John's nice idea of a paused simulation between calls to sc_start):

NOT_STARTED // until end_of_elaboration,
PAUSED // within sc_main, after return from sc_start
RUNNING // within user processes
STOPPED // after call to sc_stop (and during end_of_simulation)

Comments?

Greetings from Oldenburg,
Philipp

On 31/03/10 16:12, john.aynsley@doulos.com wrote:
> Tor,
>
> I can see the sense in having sc_is_paused() reflect whether the scheduler
> can resume.
>
> As things stand, sc_is_running() == false implies that either simulation
> has not yet started, or sc_stop() has been called.
>
> Following sc_stop() the scheduler cannot resume, so I guess sc_is_paused()
> == false ? That would make sense to me.
> But before the start of simulation ?
>
> John A
>
>
>
>
> From:
> "Jeremiassen, Tor" <tor@ti.com>
> To:
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>
> Cc:
> Bishnupriya Bhattacharya <bpriya@cadence.com>, "Philipp A. Hartmann"
> <philipp.hartmann@offis.de>, "systemc-p1666-technical@eda.org"
> <systemc-p1666-technical@eda.org>
> Date:
> 31/03/2010 14:26
> Subject:
> RE: sc_is_running
>
>
>
> John,
>
> Just a quick issue. Should sc_is_paused() return true if sc_is_running()
> is false? I don?t think so. I think sc_is_paused() should reflect whether
> the scheduler can resume again or not.
>
>
> Tor
>
> ---
> Tor Jeremiassen, Ph.D.
> Simulation and Modeling CTO
> SDO Foundational Tools
> Texas Instruments Ph: 281 274 3483
> P.O. Box 1443, MS 730 Fax: 281 274 2703
> Houston, TX 77251-1443 Email: tor@ti.com
>
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Wednesday, March 31, 2010 6:41 AM
> To: Jeremiassen, Tor
> Cc: Bishnupriya Bhattacharya; Philipp A. Hartmann;
> systemc-p1666-technical@eda.org
> Subject: RE: sc_is_running
>
> I agree with Tor that, as presently defined, sc_is_running() indicates
> whether the simulation has terminated (effectively, whether sc_stop() has
> been called). At present, sc_is_running() stays == true between calls to
> sc_start(), and even following return from the final call to sc_start()
> provided sc_stop() has not been called.
>
> I suggest we should not re-define sc_is_running() at this point, even if
> it is arguably a misnomer.
>
> If we were to add sc_pause(), then sc_is_paused() could be defined and
> could be orthogonal to sc_is_running(). sc_is_paused() would return true
> between a call to sc_pause() and a subsequent call to sc_start(), and only
> then.
>
> Another idea. How about we define sc_start() and sc_start(time) as having
> an implicit sc_pause() at the end? Then sc_is_paused() would always return
> false when called from a running SystemC process, but would always return
> true when called directly from sc_main. Just a thought.
>
> Cheers,
>
> John A
>
>
>
> From:
> "Jeremiassen, Tor" <tor@ti.com>
> To:
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>
> Cc:
> Bishnupriya Bhattacharya <bpriya@cadence.com>, "Philipp A. Hartmann"
> <philipp.hartmann@offis.de>, "systemc-p1666-technical@eda.org"
> <systemc-p1666-technical@eda.org>
> Date:
> 30/03/2010 17:57
> Subject:
> RE: sc_is_running
>
>
>
>
>
> Thinking about this, regardless of the eventual fate of sc_pause(), there
> seem to be two pieces of information that we want to provide:
>
> - whether the simulation has terminated or not
> And
> - whether the scheduler is currently active (running)
>
> The LRM currently specifies that sc_is_running() answers the second,
> though I claim since it returns true following the return of
> sc_start(sc_time) it really answers the first. I would propose that both
> pieces of information should be made available.
>
>
> Best regards,
>
> Tor Jeremiassen
>
> ---
> Tor Jeremiassen, Ph.D.
> Simulation and Modeling CTO
> SDO Foundational Tools
> Texas Instruments Ph: 281 274 3483
> P.O. Box 1443, MS 730 Fax: 281 274 2703
> Houston, TX 77251-1443 Email: tor@ti.com
>
>
>
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> Sent: Tuesday, March 30, 2010 11:27 AM
> To: Jeremiassen, Tor
> Cc: Bishnupriya Bhattacharya; Philipp A. Hartmann;
> systemc-p1666-technical@eda.org
> Subject: RE: sc_is_running
>
> So, as things stand, on return from sc_start(10, SC_NS) without an
> sc_stop(), sc_is_running() would == true, or with an sc_stop(),
> sc_is_running() would == false.
>
> If we agreed to add sc_pause(), then I would propose that sc_pause()
> should not affect the value returned from sc_is_running(), i.e. a paused
> simulation is still running. On this other hand, we might want to add a
> new function sc_is_paused() that would return true in this circumstance?
>
> Just my two pence.
>
> John A
>
> From:
> "Jeremiassen, Tor" <tor@ti.com>
> To:
> Bishnupriya Bhattacharya <bpriya@cadence.com>, "Philipp A. Hartmann"
> <philipp.hartmann@offis.de>, "john.aynsley@doulos.com"
> <john.aynsley@doulos.com>
> Cc:
> "Michael (Mac) McNamara" <mcnamara@cadence.com>,
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> Date:
> 30/03/2010 16:41
> Subject:
> RE: sc_is_running
>
>
>
>
>
>
>
>
> Regarding the semantics of sc_is_running, I would like to bring up one
> item that I proposed a few weeks back, and that is the ability to pause
> the simulation and return from sc_start() in a restartable manner.
> (Whether this should be done by allowing a resumption of simulation
> following an sc_stop() or if a separate function, such as sc_pause(),
> should be added is a slightly separate manner). However, the issue of what
> sc_is_running() should return when the simulation is "paused" then becomes
> an issue. I guess this is still an issue currently if sc_start(sc_time )
> is called and then returns. The scheduler is not running, but is in a
> sense paused and restartable (unlike a return from sc_start() due to
> sc_stop()).
>
> Should sc_is_running() return true only if the scheduler is active, or
> until the simulation is terminating? Should there be a separate call that
> indicates if the simulation is suspended but restartable (i.e., the
> scheduler is not running, but the simulation has not terminated).
>
> Best regards,
>
> Tor Jeremiassen
>

[snip]

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