Re: sc_is_running

Tor,

it could possibly be helpful to distinguish between early/regular
instantiations of modules (before before_end_of_elaboration, so to
speak) and during before_end_of_elaboration (although I don't see any
immediate need).

  But strictly speaking, IIRC elaboration starts immediately from the
call to sc_elab_and_sim up to the first call to sc_start. So the names
you proposed for the early phases may not be very accurate?

Philipp

On 31/03/10 18:27, Jeremiassen, Tor wrote:
>
> 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/
>

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