RE: sc_pause

John,

Our mails crossed in ether!

For Alan's first case below,

  sc_start(100, SC_NS); // inside here the code calls sc_pause at say time = 50 ns
  sc_start (100, SC_NS); // this would resume at 50 ns

yes, when the first sc_start() returns due to sc_pause() having been called, the time stamp should be the time at which sc_pause() was called. This is consistent with what happens for sc_stop().

About SC_STOP_IMMEDIATE, I raised the same concern in my other mail. I'm in favor of not paying attention to sc_stop_mode for pause, and instead always finish the delta cycle, unless Tor (or someone else) has a legitimiate use model that cannot be modeld w/o immediate stopping.

Thanks,
-Bishnupriya

________________________________
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Wednesday, November 10, 2010 3:47 PM
To: Jeremiassen, Tor; P1666 Technical WG
Subject: RE: sc_pause

Tor, All,

I too agree with David's idea to add a recommendation that sc_stop() should be called from sc_main() with the reason that it will cause end_of_simulation() to be called.

Is everyone okay with using sc_stop_mode for sc_pause?

Given a call to sc_pause() within sc_start(T), T>0, what should be the value of simulation time? As Alan suggested, I would propose that it is the time of the pause rather than +T.

I think we do have an issue to resolve regarding sc_pause() with SC_STOP_IMMEDIATE. What happens to any runnable processes that were pre-empted by the sc_pause()? Are they deleted from the set of runnable processes, or do those processes remain runnable on a subsequent call to sc_start()? Is this perhaps a reason to NOT support sc_stop_mode for sc_pause, but to insist that the current delta cycle is completed before returning from sc_start?

Thanks,

John A

From: "Jeremiassen, Tor" <tor@ti.com>
To: David C Black <dcblack@xtreme-eda.com>, John Aynsley <john.aynsley@doulos.com>
Cc: P1666 Technical WG <systemc-p1666-technical@eda.org>
Date: 09/11/2010 18:46
Subject: RE: sc_pause

________________________________

I agree with the proposal. David's idea has merit.

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<mailto:tor@ti.com>
________________________________
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of David C Black
Sent: Monday, November 08, 2010 9:04 AM
To: John Aynsley
Cc: P1666 Technical WG
Subject: Re: sc_pause
I'm good with the proposal. It might be good to add a clarifying statment:
sc_stop() should be called within sc_main if a decision is made not to resume (sc_start) simulation. This allows end_of_simulation() callbacks to be properly invoked.
NOTE: I would probably add the following code after the last sc_start() as a matter of best practices:
if (sc_get_status() && SC_PAUSED) {
  SC_REPORT_WARNING(MSGID, "Simulation stopped running from SC_PAUSED");
  sc_stop();
}
On Nov 8, 2010, at 7:59 AM, john.aynsley@doulos.com<mailto:john.aynsley@doulos.com> wrote:
Folks,
The next topic to finish off is the addition of sc_pause and sc_get_status, as originally proposed by Tor. We got to the point of being almost ready to close this discussion months ago. I  summarize the current proposal below. Please give this your careful consideration and either vote "yes" or raise any objections you may have.
Thanks,
John A
Add a function sc_pause that is similar to sc_stop except that it puts simulation into the paused state. Simulation can be restarted from the paused state by calling sc_start again.
sc_pause uses sc_stop_mode to determine precisely when to pause (or we could introduce a new sc_pause_mode, if people wish)
sc_pause leaves the simulation time at its current value such that sc_start would continue from that time
On return from  sc_start without sc_stop having been called, the simulation is left in the paused state. On return from  sc_start after sc_stop has been called, the simulation is left in the stopped state. In either case, simulation will remain in the running state until all processes have ceased executing prior to the return from sc_start
Make a change to the scheduler spec such that on return from sc_start() due to event starvation, the simulation time remains at the time of the last event. This can only come about after every process has either terminated or executed wait(...) with no time-out.
When paused, sc_is_running() shall return true.
Change the LRM such that sc_is_running() is not obliged to return false when called from a destructor; sc_is_running would return true unless sc_stop had been called
Add a global function sc_get_status whose value is a bit mask, used as follows:
if (sc_get_status() & (SC_PAUSED |
                                       SC_STOPPED |
                                       SC_END_OF_SIMULATION) )
     ...
The full list of simulation phases is:
       SC_ELABORATION
       SC_BEFORE_END_OF_ELABORATION
       SC_END_OF_ELABORATION
       SC_START_OF_SIMULATION
       SC_RUNNING
       SC_PAUSED
       SC_STOPPED
       SC_END_OF_SIMULATION
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
------------------------------------------------------
David C Black, XtremeEDA ESL Practice Leader
http://www.Xtreme-EDA.com<http://www.xtreme-eda.com/>
(Consulting, Services & Training for all your ESL, verification and DFT needs)
Voice: 512.850.4322 Skype: dcblack FAX: 888.467.4609
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.