RE: sc_is_running

Philipp,

I like it, and it allows us to enrich the status a little more. I would suggest if we do this, that we add to the status the timing points of the callbacks, such that maybe there's:

NOT_STARTED, // before calling sc_start
ELABORATION, // up to the first call to end_of_elaboration
END_OF_ELABORATION,
RUNNING,
PAUSED,
STOPPED,

This would allow a piece of code that is called during different times of the simulation to adjust its behavior to the current simulator state.

Or is it overkill?

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
|-----Original Message-----
|From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
|Sent: Wednesday, March 31, 2010 11:21 AM
|To: john.aynsley@doulos.com
|Cc: Jeremiassen, Tor; Bishnupriya Bhattacharya; systemc-p1666-
|technical@eda.org
|Subject: 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.