RE: sc_pause

John,

The blind spot might instead be mine. Yes both

sc_pause();
wait(SC_ZERO_TIME);

as well as

sc_pause();
next_trigger(SC_ZERO_TIME);
return;

should both do the right thing.

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<mailto:tor@ti.com>
________________________________
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Wednesday, November 10, 2010 10:03 AM
To: Jeremiassen, Tor
Cc: alan.fitch@doulos.com; Bishnupriya Bhattacharya; owner-systemc-p1666-technical@eda.org; systemc-p1666-technical@eda.org
Subject: Re: sc_pause
Tor,
Perhaps I have a blind spot, but I cannot see why the following would not be sufficient:
        sc_pause();
        wait(SC_ZERO_TIME);
John A
From:
"Jeremiassen, Tor" <tor@ti.com>
To:
Bishnupriya Bhattacharya <bpriya@cadence.com>
Cc:
"alan.fitch@doulos.com" <alan.fitch@doulos.com>, "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "owner-systemc-p1666-technical@eda.org" <owner-systemc-p1666-technical@eda.org>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
10/11/2010 13:52
Subject:
Re: sc_pause
________________________________
To Bishnupriya's point about a resume event: Would it make sense for sc_pause() to return an event reference that could be used in a wait() or next_trigger()?
Best regards
Tor Jeremiassen
Sent from my iPhone
On Nov 10, 2010, at 4:22 AM, "Bishnupriya Bhattacharya" <bpriya@cadence.com<mailto:bpriya@cadence.com>> wrote:
John,
Did you respond to Alan's second question below? If you did, I missed it. I've the same question:
Suppose sc_main() calls sc_start(), and a process calls sc_pause(SC_STOP_IMMEDIATE). This will make sc_start() return to sc_main() right after the current process finishes, and while there maybe processes remaining in the runnable q. When the next sc_start() is issued from sc_main(), I suppose these runnable processes should all execute? What happens to the delta cycle count? Should the delta cycle count be the same? Essentially here the eval phase of one delta cycle is spanning across two sc_start() calls and across stuff that can happen in between in sc_main(). Does this seem a little worrisome? e.g. if one of the runnable processes gets killed in sc_main() before the next sc_start()? Well that actually is taken care of by kill() semantics. Could anything else unexpected happen? In any case, we need to clarify the behavior here. For sc_stop(), we do not need to deal with this because simulation cannot resume.
"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"
Clarification: If sc_start(100, SC_NS) returns to sc_main() w/o any sc_pause() having been called, what does sc_sim_status() return? What if sc_start() returns because of sc_pause()? In either cases, both the SC_RUNNING bit and SC_PAUSED bit is set?
One final comment. sc_pause() is an useful mechanism by which a process is interrupting/pausing the simulation. In a SystemC simulator with an interactive prompt, it can provide a natural point where control can return to the prompt - similar to making sc_start() return - and users can introspect or configure things perhaps at the prompt. Now suppose a process determines that it needs some configuration/user-input, and it calls sc_pause() to that purpose. But it further wants to wake up and get scheduled when simulation resumes again. Is it warranted to provide an event that is notified when simulation is resumed again with sc_start()? This could be made generic, and not tied particularly to sc_pause()/resumption - e.g. sc_start() can always notify an event at its onset.
void run() {
  while (1) {
    // do stuff
    if (condition) {
      sc_pause();
      wait(sc_simulation_resume_event); // or wait(sc_start_event)
      ...
    }
  }
}
We also have the option of tying it entirely to sc_pause() and making it less generic - e.g. "sc_pause(bool block = false)". If you call sc_pause(true) from thread process then it will block till simulation is resumed again with sc_start() - the specifics can be left implementation defined. The Cadence simulator has had a similar pause() functionality, and this blocking feature has been found to be useful. What do people think?
Thanks,
-Bishnupriya
________________________________
From: owner-systemc-p1666-technical@eda.org<mailto:owner-systemc-p1666-technical@eda.org> [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of alan.fitch@doulos.com<mailto:alan.fitch@doulos.com>
Sent: Monday, November 08, 2010 7:41 PM
To: john.aynsley@doulos.com
Cc: owner-systemc-p1666-technical@eda.org; systemc-p1666-technical@eda.org; Jeremiassen, Tor
Subject: Re: sc_pause
Hi John,
 a couple of questions:
just to clarify, if I had in sc_main
 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
Secondly, if I called
  sc_start(SC_ZERO_TIME);  // call sc_pause with SC_STOP_IMMEDIATE during the evaluation phase
 // now what happens? do other runnable processes complete the rest of the delta above when resumed
 sc_start(1, SC_NS);
regards
Alan
--
Alan Fitch
Senior Consultant
Doulos - Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel:  + 44 (0)1425 471223                       Email: alan.fitch@doulos.com<mailto:alan.fitch@doulos.com>
Fax:  +44 (0)1425 471573                        http://www.doulos.com<http://www.doulos.com/>
--------------------------------------------------------------------------------
Doulos Ltd is registered in England and Wales with company no. 3723454
Its registered office is 4 Brackley Close, Bournemouth International Airport,
Christchurch, BH23 6SE, UK.
This message (and associated files) may contain information that is confidential,
proprietary, privileged, or subject to copyright. It is intended solely for the use
of the individual to whom it is addressed and others authorised to receive it. If
you have received this email in error, please notify the sender and delete all
copies. This message may contain personal views which are not the views of
Doulos, unless specifically stated.
From:
john.aynsley@doulos.com<mailto:john.aynsley@doulos.com>
To:
systemc-p1666-technical@eda.org<mailto:systemc-p1666-technical@eda.org>
Cc:
"Jeremiassen, Tor" <tor@ti.com<mailto:tor@ti.com>>
Date:
08/11/2010 13:59
Subject:
sc_pause
Sent by:
owner-systemc-p1666-technical@eda.org<mailto:owner-systemc-p1666-technical@eda.org>
________________________________
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.
--
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.