sc_pause

All,

I include below a revised summary of the proposal to add sc_pause,
including the finer points of integrating sc_pause with the scheduler and
with other features such as event notifications and process control
methods.

The following has been analysed pretty thoroughly and all points have been
agreed either on the reflector or in side-conversations. Of course, feel
free to comment if you see any holes!

John A

Change sc_start() to return with sc_time_stamp() equal to the time of the
most recent event or time-out (more useful than having time = infinity)

sc_start(T) or sc_start(T, RUN_TO_TIME), T > 0, returns with
sc_time_stamp() advanced by T (the old behavior)

sc_start(T, SC_EXIT_ON_STARVATION), T > 0, returns with sc_time_stamp()
equal to the time of the most recent event or time-out if the process,
update, and delta notification queues are empty at +T

sc_start(T ...) runs up-to-and-including any timed notification phase that
may occur at time +T (no change)

sc_start(SC_ZERO_TIME) runs for a single delta cycle, i.e. 1 eval phase, 1
update phase, 1 delta notification phase (no change)

Add a function sc_pause that puts simulation into the paused state.
Simulation can be restarted from the paused state by calling sc_start
again.

If sc_pause is called, simulation will remain in the running state until
all processes have yielded prior to the return from sc_start. On return
from sc_start without sc_stop having been called, the simulation is left
in the paused state (whether or not sc_pause was called). On return from
sc_start after sc_stop has been called, the simulation is left in the
stopped state.

After a call to sc_pause, the scheduler completes the current delta cycle
before returning from sc_start.

When sc_start is called again from the paused state, the scheduler resumes
from the evaluation phase of the next delta cycle

It is possible to call request_update() of a primitive channel before or
between calls to sc_start. Calls made between calls to sc_start are
executed as if made in the first evaluation phase after resuming the
scheduler

It is possible to execute delta or timed notifications before the first
call to sc_start, but not immediate notifications.

It is possible to execute immediate, delta, and timed notifications when
in the paused state between calls to sc_start. They behave as if executed
in the first evaluation phase after resuming the scheduler

sc_stop() overrides sc_pause(). sc_pause() is ignored following sc_stop()

We add a recommendation that an application should call sc_stop() from
sc_main() at the end of simulation, e.g.
  if (sc_get_status() && SC_PAUSED) {
    SC_REPORT_WARNING(MSGID, "Simulation stopped running from SC_PAUSED");
    sc_stop();
  }

The following process control methods are permitted from sc_main while
simulation is paused:
  suspend
  resume
  disable
  enable
  sync_reset_on
  sync_reset_off
 
The following are NOT permitted
  kill
  reset
  throw_it

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

sc_is_running() returns true only when sc_get_status() is SC_RUNNING or
SC_PAUSED

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

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.