RE: reset_event

Yossi,

Yes, all the process control methods (with the one exception of disable) are immediate in the sense that they have their effect in the current evaluation phase. E.g suspend removes a process from the runnable set immediately, resume makes a process runnable in the current evaluation phase immediately, reset swaps in the reset process and calls it again from-the-top immediately, and so on. The only hint of a delta cycle in the process control extensions is that disable does not take effect until the end of the current evaluation phase.

John A

-----"Veller, Yossi" <Yossi_Veller@mentor.com> wrote: -----
To: <john.aynsley@doulos.com>, "Philipp A. Hartmann" <philipp.hartmann@offis.de>, <bpriya@cadence.com>, <systemc-p1666-technical@eda.org>
From: "Veller, Yossi" <Yossi_Veller@mentor.com>
Date: 11/25/2010 03:21PM
Subject: RE: reset_event

I object to the immediate notification for the reset event.
Immediate notification is a source for dependence of the simulation results on the simulator’s scheduler and a basis for non parallelizable code (e.g. in such implementation the reset action may come after the reset thread executes) . SystemC had chosen to provide immediate notification for the user to use upon his/her responsibility. However I think that immediate notification should not be a ‘standard’ behavior of operations provided by the kernel.
 
BTW Are there other proposed implicit immediate notifications?
 
Regards
Yossi
 

From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Monday, November 15, 2010 12:27 PM
To: Philipp A. Hartmann; bpriya@cadence.com; systemc-p1666-technical@eda.org
Subject: Re: reset_event 
Philipp, All,

You raise some interesting questions.

Re. when reset_event() is notified, I cannot see that it makes any difference "when" it is notified relative to the reset action (assuming notify() is called from reset(), of course, which it has to be) because the effect of an immediate event notification is merely to make some processes runnable. Any such processes will not actually be executed until the current process yields (the one calling reset()).

When sc_pause() is called (or sc_stop() is called, for that matter) all kinds of activity can indeed be scheduled before the calling process yields. This activity includes event notifications (immediate, delta, and timed) and process control calls (including immediate ones). Any activity scheduled for the current evaluation phase will be executed before simulation is paused or stopped, so there could be a long chain of immediate notifications. sc_get_status() == SC_RUNNING during such execution. On return from sc_start(), the set of runnable processes will be empty, although there may exists update requests and delta notifications.

When sc_start() is called again, the set of runnable processes will still be empty, so the schedule will jump to processing request_updates and delta notifications. We must specify that the delta_cycle count shall only get incremented once between evaluation phases across the pause.

After return from sc_start() the main scheduler loop is not running, although request_update() may be called to schedule update requests.

We do need to consider which process control methods may be called when simulation is paused:

suspend - yes?
resume - yes?
disable - yes?
enable - yes?
sync_reset_on/off - yes?

kill - no?  (permitted during elaboration, but during elaboration there is no call stack to unwind)
reset - no? (permitted during elaboration, but during elaboration there is no call stack to unwind)
throw_it - no! (may only be called from a process)

In other words, I am proposing that the immediate semantics of the process control methods can only be executed during simulation.

After calling sc_pause() or sc_stop(), simulation is still running until return from sc_start(). Right now there is no way to ask the kernel whether sc_pause() or sc_stop() have been called. It is legal (a warning) to call sc_stop() more than once. So, what should happen if sc_stop() is called after sc_pause() or sc_pause() after sc_stop() before the calling process has yielded?

Should sc_stop() take precedence over sc_pause()?

Do we want to add:

        bool sc_stop_called() const;
        bool sc_pause_called() const;

Thanks,

John A

 From: "Philipp A. Hartmann" <philipp.hartmann@offis.de> To: john.aynsley@doulos.com Cc: bpriya@cadence.com, systemc-p1666-technical@eda.org Date: 12/11/2010 23:46 Subject: Re: reset_event 

John, Bishnupriya,

I agree with having immediate notification of reset_event.  We should
probably require, that this event is notified "after" the reset action
has been performed, though.

But I'm somewhat puzzled about the interaction of sc_pause and the
reset/terminated events.  Due to the immediate semantics and the
immediate notification of these events, all kinds of model activity
could be triggered during SC_PAUSED, when processes are reset from
within sc_main.

 This feels indeed worrisome to me, as Bishnupriya put it in an earlier
mail.  Do we need to require, that this implicit/immediate evaluation
phase at least sets the status back to SC_RUNNING?  Or do we want to
prohibit this use of kill/reset/throw_it from in between calls to sc_start?

Thanks,
Philipp

On 12/11/10 16:40, john.aynsley@doulos.com wrote:
> Bishnupriya,
>
> I am just trying to pin down the semantics of reset_event().
>
> Every flavor of reset, namely
>
> * reset()
> * resumption while in the synchronous reset state
> * async_reset_signal()
>
> is ultimately equivalent to a call to reset() happening during an
> evaluation phase. We want this to cause the notification of the event that
> will be returned by the new method reset_event(). I can see two
> possibilities:
>
> * The reset event is notified using an immediate notification, in which
> case any processes sensitive to the reset event will become runnable in
> the same evaluation phase in which reset() is called
>
> or
>
> * The reset event is notified using a delta notification, in which case
> any processes sensitive to the reset event will become runnable one delta
> cycle later.
>
> The immediate notification feels right to me.
>
> What do you think?
>
> Thanks,
>
> John A
>
>
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
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. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.