RE: reset_event

Bishnupriya, Philipp,

I will answer both your previous emails together.

Re. the timing of reset_event(), all 4 forms of reset

* Explicit call to reset()
* sync_reset_on
* reset_signal_is
* async_reset_signal_is

... end up resetting the target process with the same same semantics as
would a call to the reset() method. The obvious way to implement this
would be for the implementation to actually call reset() in each case,
although it does not have to. This implies that sc_unwind_exception gets
thrown in each case. Hence my statement that all that is required is that
the reset event must be notified from reset(). It cannot matter whether
the reset_event is notified before or after the sc_unwind_exception is
thrown, because any handler for the sc_unwind_exception is not permitted
to yield.

Re. calling notify from sc_main, I had tacitly assumed this would be
forbidden by generalizing from 6.10.3 "events shall only be notified
during simulation". I tacitly assumed that "during simulation" in this
context meant "from sc_start". I would claim that there is no precedent
for allowing notify to be called from sc_main. This would in effect be
allowing simulation to "leak out" from the scheduler. In 1666-2005 the
only scheduler-related calls permitted during elaboration or from sc_main
are request_update() and dont_initialize(). I accept the process control
methods like suspend() and kill() as a reasonable extension to this, but I
would claim that event notifications should be disallowed outside
sc_start() unless someone has a really convincing argument.

The terms "during elaboration" and "during simulation" have always been
problematic in the LRM, and I need to revisit them again with the addition
of sc_pause.

Whether "delta cycles are naturally incremented by simply starting the
scheduler again" depends on where in the cycle the scheduler starts and
where in the cycle the delta_count is incremented, the point being that in
the initialization phase, the scheduler starts from the update phase, i.e.
"half way through" the delta cycle. This is in order to "mop up" and calls
to request_update() that were made during elaboration. I am proposing that
the scheduler restarts from the update phase after a pause for the same
reason.

Bishnupriya points out that we have options when to return from sc_start()
after a call to sc_pause()

Option 1: Pause the scheduler after evaluation but before update
Option 2: Pause the scheduler after update but before delta notification
Option 2: Pause the scheduler after the delta notification phase

I agree any of these could be made to work, BUT... we are permitting
calls to request_update() from sc_main while simulation is paused (which
is a natural extension of the fact that request_update() can be called
during elaboration). Hence when the scheduler restarts, there may be
pending activity on the request update queue. Hence I would claim that on
calling sc_start() again, the first action of the scheduler MUST be to
execute the update phase, as is the case during initialization, and for
the same reason; running processes need to "see the new value" of any
signals that had new values forced onto them in between the cracks of
time, while the scheduler was paused.

Hence I assumed Option 1. If we went for Options 2 or 3 (which I agree are
possible) then I claim that we would have to re-run the update and/or
delta notification phases when simulation restarts. If we allowed event
notifications while simulation is paused (which I oppose), then I think
all bets are off; we should then have to revisit the issue of whether
event notifications are permitted during elaboration and how event
notifications get synchronized with update requests when the scheduler
restarts (which I guess is all possible, but personally I do not want to
go there).

I am fine with the proposal that sc_stop() takes precedence over
sc_pause() and we do not need any additional status functions.

John A

From:
Bishnupriya Bhattacharya <bpriya@cadence.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>, "Philipp A. Hartmann"
<philipp.hartmann@offis.de>, "systemc-p1666-technical@eda.org"
<systemc-p1666-technical@eda.org>
Date:
15/11/2010 19:12
Subject:
RE: reset_event

John, Philip,
 
I agree with immediate notification of reset_event.
 
Comments below on rest of discussion.

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Monday, November 15, 2010 3:57 PM
To: Philipp A. Hartmann; Bishnupriya Bhattacharya;
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()).
 
>>> [bpriya: or the resetee itself has gotten the chance to execute from
beginning and yield, in case of synchronous reset, where the kernel will
immediately notify the resume_event]
 
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.
 
>>> [bpriya: this is option 1 - essentially sc_start() is returning in the
middle of a delta cycle, after eval but before update(). Another option
(option 2) would be to finish the delta cycle, including update phase and
probably delta notification phase too before returning from sc_start(). In
this case, one delta cycle has finished, and the other hasn't started yet,
and there maybe processes in runnable q for next eval phase when sc_start
returns.]

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.
 
>>> [bpriya: things are a little more iffy here. When sc_start() is called
again, the set of runnable processes is not necessarily empty because
sc_main() can immediately notify an event, and make sensitive processes
runnable, right? This is already true today. This sitn. is awkard for
option 1, because we broke in the middle of delta after eval with an empty
runnable q, and now the q is no longer empty - where do the new processes
execute? As a continuation of last eval, or as part of next eval? For
option 2), it is cleaner. A delta had finished, possibly with existing
processes in runnable q for next eval - The new processes in runnable q
from sc_main also become part of next eval.]
 
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?
 
>>> [bpriya: yes on all of the above]
 
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.
 
>>> [bpriya: Agreed. It will be strange to have stack unwinding code
execute in between sc_start() calls when a delta cycle is not active, and
even stranger to execute process code itself (in case of reset). Note that
it is ok to write to signals that trigger async_reset_signal_is() since
the effect will not kick in immediately.]

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()?
 
>>> [bpriya: yes]
 
Do we want to add:

        bool sc_stop_called() const;
        bool sc_pause_called() const;
 
>>> [bpriya: no, not really necessary]
 
Thanks,
-Bishnupriya
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.