Re: sc_is_running

Very good idea Tor.

Philipp: I think that strictly speaking "elaboration" is not what you
describe,
as according to the norm, it includes the construction of the module
hierarchy. If you have static modules, then their construction
happens before the call to sc_elab_and_sim(), and so does the
elaboration? (unless we forbid this explicitly).

I think to enhance the proposal then, we have to align the various
enum values to the possible "times" where the call can indeed be done,
and so with the various possible callbacks.

So to summarize we have got:

BEFORE_SC_ELAB_AND_SIM (bad name, but you understand me)
BEFORE_END_OF_ELABORATION
END_OF_ELABORATION
START_OF_SIMULATION
RUNNING
PAUSED
STOPPED
END_OF_SIMULATION

I would be more specific for PAUSED: after the return from sc_start(sc_time)
due to time reached or call to sc_pause().

We have to take into account the case of a call to sc_start(void), which wil
run up to completion, and cannot be restarted I believe...

So for STOPPED: after the return from sc_start(void), or after return
from sc_start(sc_time) due to a call to sc_stop().

I am still a bit hesitating for the last one: END_OF_SIMULATION.
On one hand, it is logical with the "enum values corresponding to callbacks
when they exist" idea, but on the other hand, maybe it could be beneficial
when in end_of_simulation() to know if the simulator PAUSED or STOPPED.

What do you think?

Jerome

On 3/31/2010 7:06 PM, Philipp A. Hartmann wrote:
> 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/
>>
>>
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.