RE: sc_pause

From: Bishnupriya Bhattacharya <bpriya@cadence.com>
Date: Tue Nov 09 2010 - 01:45:54 PST

John,

I believe this issue is now moot.

The refsim implementation in SystemC 2.2.0 correctly implements sc_start(0) to execute one delta cycle, as per the LRM defnition.

Furthermore, the LRM has also added the definition of sc_pending_activity_at_current_time(). Using a combination of sc_start(0) and sc_pending_activity_at_current_time(), it is also possible to execute all delta cycles at the current time.

Hence, as it stands, both modeling scenarios can be sucessfully modeled, and no LRM additions/modifications are necessary.

Thanks,
-Bishnupriya

________________________________
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Monday, November 08, 2010 7:48 PM
To: alan.fitch@doulos.com
Cc: owner-systemc-p1666-technical@eda.org; systemc-p1666-technical@eda.org; Jeremiassen, Tor
Subject: Re: sc_pause

Further to this, Bishupriya raised the following issue several years ago(!)

4.3.4.2 IEEE 1666 defines sc_start(0) to execute ONE delta cycle (Section 4.3.4.2). The refsim implementation has always implemented sc_start(0) to execute ALL delta cycles at the current time - i.e. sc_start(0) is the equivalent of the deprecated sc_cycle(0). Excerpts from 1666 and systemc-2.1v1 RELEASENOTES are given below, along with a simple program and its output obtained from Systemc-2.2.05jun06_beta release. If the sc_start(0) call is replaced with sc_cycle(0) in the test, the same output is obtained with additional deprecation messages for sc_cycle. Which definition is right in this case? Whichever one is, we have a hole in expressing the other one, and it seems users may legitimately want to do both in their designs.

From: Alan Fitch/doulos
To: john.aynsley@doulos.com
Cc: owner-systemc-p1666-technical@eda.org, systemc-p1666-technical@eda.org, "Jeremiassen, Tor" <tor@ti.com>
Date: 08/11/2010 14:10
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
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
To:     systemc-p1666-technical@eda.org
Cc:     "Jeremiassen, Tor" <tor@ti.com>
Date:   08/11/2010 13:59
Subject:        sc_pause
Sent by:        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.
Received on Tue Nov 9 01:46:33 2010

This archive was generated by hypermail 2.1.8 : Tue Nov 09 2010 - 01:46:37 PST