RE: sc_is_running

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
---
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: Bishnupriya Bhattacharya [mailto:bpriya@cadence.com]
|Sent: Tuesday, March 30, 2010 4:18 AM
|To: Philipp A. Hartmann; john.aynsley@doulos.com
|Cc: Michael (Mac) McNamara; systemc-p1666-technical@eda.org; Jeremiassen,
|Tor
|Subject: RE: sc_is_running
|
|I agree with Philip. The LRM should reword itself along the lines of:
|
|"If simulation has been explicitly ended (either by calling sc_stop() or 
by
|any other means available to an implementation), sc_is_running() shall
|return false when called from destructors of objects in the module
|hierarchy. If simulation has not been explicitly ended, ......"
|
|So the current reference inplementation behavior will be legal according 
to
|the LRM.
|
|Thanks,
|-Bishnupriya
|
|
|
|-----Original Message-----
|From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
|Sent: Tuesday, March 30, 2010 2:06 PM
|To: john.aynsley@doulos.com
|Cc: Michael (Mac) McNamara; systemc-p1666-technical@eda.org; Jeremiassen,
|Tor; Bishnupriya Bhattacharya
|Subject: 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.