Re: sc_is_running

John, All,

sorry for jumping in that late. Just as brief comments:

  I think we need to fix the LRM that an implementation does NOT have to
return false from sc_is_running during the destructor calls. I don't
see a possible implementation for this (at least in an sc_main/sc_start
based environment).

  I think, dropping this requirement should be enough, since in case of
called end_of_simulation callbacks, it would even return false during
the destruction.

  There's no problem in calling sc_stop from within sc_main after the
last call to sc_start, right? (at least in practice) This is an easy
solution for the user to ensure calls to end_of_simulation. But I don't
see how to automate this without breaking existing models.

Greetings from Oldenburg,
Philipp

On 26/03/10 16:59, john.aynsley@doulos.com wrote:
> All,
>
> The LRM currently says that sc_is_running shall return:
>
> false during elaboration
> false from start_of_simulation
> true during initialization
> true while the scheduler is running (during simulation)
> false from end_of_simulation
> false from the destructor of any object in the module hierarchy
>
> The LRM does not directly relate the behavior of sc_is_running to sc_stop
>
> The LRM says that sc_stop causes the scheduler to halt, which in turn
> causes end_of_simulation to be called
>
> The LRM says nothing about what happens if sc_stop is NOT called: by
> inference, simulation just "runs off the end", but sc_is_running is
> required to be false in the module destructors
>
> The LRM says that a simulator that does not make use of sc_start shall
> call end_of_simulation "at the very end of simulation" regardless of
> whether sc_stop is called. The OSCI simulator, does make use of sc_start,
> but does not call end_of_simulation unless sc_stop has been called (and is
> therefore 1666-compliant).
>
> If sc_stop is called, the OSCI sim behaves as expected.
> If sc_stop is not called, the OSCI sim has sc_is_running() == true on
> return from sc_start() and in the destructors, CONTRADICTING the LRM
>
> As Tor says, sc_is_running() is indeed true up until the end_of_simulation
> callbacks.
>
> Mac's check will indeed work
>
> My gripe was that the value of sc_is_running() on return from sc_start()
> has to be inferred from the above rules. If sc_stop has been called then
> everything is clear: sc_is_running() will be false. But what if sc_stop
> has not been called?
>
> - Is an implementation allowed to insert end_of_simulation() callbacks
> before returning from sc_start?
> - The OSCI sim has sc_is_running() == true in the destructors. Is this a
> bug, or should we change the LRM?
>
> I just want to make these details explicit.
>
> Cheers,
>
> John A
> Nit-picker.
>
>
>
>
> From:
> "Michael (Mac) McNamara" <mcnamara@cadence.com>
> To:
> "Jeremiassen, Tor" <tor@ti.com>, Bishnupriya Bhattacharya
> <bpriya@cadence.com>, "john.aynsley@doulos.com" <john.aynsley@doulos.com>,
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> Date:
> 25/03/2010 16:17
> Subject:
> RE: sc_is_running
>
>
>
> Or perhaps sc_is_running() should return false during the
> end_of_simulation call backs, so they could be coded to check this status
> in order to guide their behavior. For example, a given routine that is
> called in general, and also from end_of_simulation call backs might want
> to check sc_is_running before invoking an action that would schedule
> something.
>
>
> Michael McNamara
> VP&GM System Software
> Cadence Design Systems
> mcnamara@cadence.com
> From: owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Jeremiassen,
> Tor
> Sent: Thursday, March 25, 2010 4:26 AM
> To: Bishnupriya Bhattacharya; john.aynsley@doulos.com;
> systemc-p1666-technical@eda.org
> Subject: RE: sc_is_running
>
> That sounds good. In fact, it would seem reasonable for sc_is_running() to
> be true up until the end_of_simulation callbacks.
>
> 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: owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Bishnupriya
> Bhattacharya
> Sent: Thursday, March 25, 2010 4:34 AM
> To: john.aynsley@doulos.com; systemc-p1666-technical@eda.org
> Subject: RE: sc_is_running
>
> John,
>
> If I understrand your question correctly, in between or after calls to
> sc_start(), sc_is_running() should return true if simulation has not
> ended, and false otherwise. For example, see code below.
>
> int sc_main(...) {
> ...
> sc_start(100, SC_NS); <---------------- sc_stop() is not called and
> sc_start() returns to sc_main
> assert(sc_is_running() == true);
> sc_start(); <---------------- sc_stop() is called from a thread process
> at time 200 ns, and sc_start() returns to sc_main
> assert(sc_is_running() == false);
> return 0;
> }
>
> non-OSCI simulators may have other ways of ending simulation besides
> sc_stop(), but the behavior of sc_is_running() will still be the same if
> the wording is done in terms of "end of simulation" instead of in terms of
> sc_stop(), which is what the current wording is.
>
> Does that sound right?
>
> Thanks,
> -Bishnupriya
>
>
> From: owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of
> john.aynsley@doulos.com
> Sent: Thursday, March 25, 2010 2:28 PM
> To: systemc-p1666-technical@eda.org
> Subject: sc_is_running
> The LRM is ambiguous about the value of sc_is_running() when called from
> sc_main between or after calls to sc_start(). In the OSCI implementation,
> sc_is_running returns true between or after calls to sc_start(), but then
> the OSCI sim does not call end_of_simulation unless sc_stop is explicitly
> called.
>
> Comments? Do we want the LRM to specific the value of sc_is_running() as
> per the behavior of the OSCI sim?
>
> Thanks
>
> John A
>
>

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