Re: reset_event

Philipp, All,

I have just realized that we made a sideways swerve in the middle of this
discussion. We started with the point that sc_is_running() could not be
guaranteed to be false when called from a destructor because sc_stop()
might not have been called, and hence the LRM needed to change so that
sc_is_running() could still be true in a destructor.

However, we then introduced sc_pause.

As I understand it, the current proposal is:

        sc_start(any_argument_list_you_like);

        sc_assert( sc_get_status() & (SC_IS_PAUSED | SC_IS_STOPPED );
        sc_assert ( sc_is_running() == false );

Hence I believe the current proposal implies that sc_is_running() == false
when called from a destructor, after all.

Is that correct?

John A

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

John,

I agree with your analysis and the proposed semantics.

Wrt to 'during simulation' and sc_main: sc_is_running would (still?)
return true after the first invocation to sc_start unless sc_stop has
been called. So this would be "during simulation"?

But I agree, that we should clarify this, since sc_get_status would
return SC_PAUSED within sc_main. So strictly speaking, we're not during
simulation...

Thanks,
Philipp

On 16/11/10 11:02, john.aynsley@doulos.com wrote:
> 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

-- 
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 · http://www.offis.de/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.