Re: P1666 surprising result with immediate notification

Bishnupriya, John, All,

I haven't been aware of the corner case Bishnupriya has raised in her
last mail that threads may be immediately triggered by their static
sensitivity even though they yield with an explicit wait(ev), with ev
not being part of the static sensitivity. I agree, that this is
definitely bad.

  Therefore, I agree that we should change the rules that static
sensitivity is not considered while the process is running (similar to
Verilog).

  Using next_trigger as it is now (having an effect depending on the
order of statements in the body) feels consistent to me. Moreover,
within an SC_METHOD a re-trigger could be used for the modelling of
complex explicit state machines.

  I have the feeling that changing wait(ev) to have immediate effect
could break existing models, since then suddenly processes may be
re-triggered that currently are guaranteed to miss the notification.
This is one of the few things you can rely on with the current immediate
semantics.

  When prohibiting self-triggers via the static sensitivity _and_ an
immediate wait(ev), we effectively remove the possibility to trigger a
thread process from within itself. I don't think that this is a
show-stopper, since in SC_THREADs you can always skip the wait and
continue their work directly. They can't rely on any process being run
in-between anyhow.

  That said, I would propose to keep the notify() call as it is now, in
the sense that it continues to respect the static sensitivity to avoid
breaking existing models that somehow rely on this. But we should
deprecate this function in favour of a notify_immediate() function, that
clearly expresses the intent and can safely follow the new rules.

  I always found it unfortunate, that one can accidentally use the
dangerous immediate notification mechanism so easily. Having an
explicit notify_immediate() could be an additional benefit.

My 2¢,
  Philipp

On 18/01/11 20:26, john.aynsley@doulos.com wrote:
> Bishnupriya, All,
>
> Back in 2005 I had assumed that neither a method process nor a thread process would have the capability to be sensitive to anything while the associated function was actually running, because that is how Verilog behaves (which does have immediate notifications). In other words, for a thread, I assumed the rule you described below. For a method, I assumed next_trigger() created the next trigger condition, but that the method process would not become a candidate to be triggered until it had returned control to the kernel.
>
> So I think we have 3 sets of rules on the table:
>
> * The "Verilog rules" (which was the intent of the 1666-2005 LRM, although not spelled out very explicitly)
> * The de facto PoC sim behavior
> * Bishupriya's rules
>
> My view on this is not principled, but purely practical. Do we fix the PoC simulator, or do we fix the rules? Is there code out there that relies on the current PoC scheduling rules? My default position would be that we have to document the PoC behavior, though I think that adopting the Verilog rules would lead to the fewest surprises. I think we might argue the case on the grounds of harmonisation between languages.
>
> Cheers,
>
> John A
>
>
> -----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----
> To: "Philipp A. Hartmann" <philipp.hartmann@offis.de>, Jerome CORNET <jerome.cornet@st.com>, David C Black <dcblack@xtreme-eda.com>
> From: Bishnupriya Bhattacharya <bpriya@cadence.com>
> Date: 01/18/2011 06:56PM
> Cc: John Aynsley <john.aynsley@doulos.com>, P1666 Technical WG <systemc-p1666-technical@eda.org>
> Subject: RE: P1666 surprising result with immediate notification
>
> Philipp, John, David, All,
>
> I agree with Philipp's excellent analysis below, except for the static sensitivity case.
>
> For a SC_METHOD, it is legitimate that next_trigger(e1) followed by notify(e1) will schedule the process in current eval.
>
> // will trigger:
> next_trigger(e1);
> e1.notify();
>
> For SC_THREAD, it is legitimate that notify(e1) followed by wait(e1) will NOT schedule the process in current eval
>
> // won't:
> e1.notify();
> wait(e1);
>
> What I don't find legitimate is that static sensitivity is triggered by immediate notification. This is because of the hole in SystemC that the effective sensitivity of a process is not defined WHILE it is running - it is an implementation artifact that the effective sensitivity during a process's execution is assumed to be its static sensitivity, which results in the method or thread below triggering in current eval, if e1 is the static sensitivity of the process. (I've raised this before in the context of the process control semantics).
>
> // will
> e1.notify();
> wait();
>
> In fact, even if the thread is changed as below to wait on another event e2 (instead of waiting for its static sensitivity), it will still be scheduled in current eval although e2 was never triggered!!!!!!! This is clearly BAD.
>
> // will
> e1.notify();
> wait(e2);
>
> IMO, the LRM should plug this hole and clearly define the state of a process's effective sensitivity when it is running. The rules below make most sense to me.
>
> 1) process's effective sensitivity is set to null when process starts executing
> 2) process can set up dynamic sensitivity by calling next_trigger in a method or wait(...) in a thread, which then becomes its effective sensitivity with immediate effect
> 3) if process does not set up dynamic sensitivity, its static sensitivity becomes its effective sensitivity AFTER method process returns or thread process yields to kernel via wait()
>
> Thoughts?
>
> Thanks,
> -Bishnupriya
>
> -----Original Message-----
> From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Philipp A. Hartmann
> Sent: Tuesday, January 18, 2011 6:51 AM
> To: Jerome CORNET; David C Black
> Cc: John Aynsley; P1666 Technical WG
> Subject: Re: P1666 surprising result with immediate notification
>
> David, Jerome, All,
>
> I'll try to give the immediate notification issue a shot. Firstly, a
> summary of my understanding of the immediate notification semantics in
> general.
>
> 1) The kernel maintains a set of runnable processes for the (current)
> evaluation phase.
>
> 2) Processes can be sensitive to events
> (either statically or dynamically, which is not important here).
>
> 3) Upon immediate notification of an event, sensitive processes are
> immediately added to the set of runnable processes.
>
> 4) If a process is already in the set of runnable processes, it's
> not added for a second time when triggered. It's a set …
>
> 5) If a process is activated, it's immediately removed from the
> set of runnable processes.
>
> Apart from the general dangers of immediate notifications, three
> corner cases have been identified by David, which are all direct
> consequences of the rules above:
>
> ạ) Processes can be triggered immediately by themselves, resulting
> in multiple invocations in a single evaluation phase.
>
> To trigger itself immediately in the same evaluation phase, a
> process needs to be sensitive to the notified event _before_
> it calls ev.notify().
>
> The reason that this works at all is the removal of the process
> from the runnable set _before_ activating the process (5).
>
> The trigger can be due to a static sensitivity (as John pointed
> out), or due to a next_trigger(ev) in an SC_METHOD:
>
> // will trigger:
> next_trigger(ev);
> ev.notify();
>
> // won't:
> ev.notify();
> �� � next_trigger(ev);
>
> b) wait(ev) is not triggered from within the current process
>
> �� // won't trigger in the current evaluation phase
> �� � �ev.notify();
> �� � �wait(ev);
>
> �� I think, this is expected. �The notification is _immediate_, which
> �� means, that all processes that are _currently_ sensitive to to event
> �� are triggered (3). �The wait(ev) call has not been reached, yet.
>
> �� We should NOT change this rule, since this may well break existing,
> �� carefully coded models.
>
> b) The number of activations of processes sensitive to immediately
> �� notified events can differ.
>
> �� � This is a general artefact of immediate notifications. �Their
> �� effect can depend on the kernel's internal scheduling order in
> �� which the set of runnable processes is activated.
>
> �� � In David's example, one process is sometimes triggered twice in a
> �� row, depending on the instantiation order. �The cause for this is the
> �� state of the set of runnable processes, when the event is notified.
>
> �� Consider the "repetition" case in the reference simulator
> �� (R being the set of runnable processes):
>
> �� � start �- R = {t2,t1}
> �� � run t2 - R = {t1}
> �� � run t1 - R = {} � �- notify ev - R = {t1,t2}
> �� � run t1 - R = {t2} �- notify ev - R = {t2,t1}
> �� � run t2 ...
>
> �� Compared to:
> �� � start �- R = {t1,t2}
> �� � run t1 - R = {t2} �- notify ev - R = {t2,t1}
> �� � run t2 - R = {t1}
> �� � run t1 - R = {} � �- notify ev - R = {t1,t2}
> �� � run t2 ...
>
> ��While I agree, that all of this can be quite surprising, I think we
> should keep the rules as they are:
>
> �� Immediate notification (3)(4) needs to be defined this way, to be
> �� actually immediate.
> �� Self-triggering (especially with next_trigger) may be useful
> �� especially for method processes.
> �� Process order dependence can not be avoided with immediate
> �� notifications.
>
> Still, it may be helpful to refine the wording in that area.

[snip]

-- 
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://offis.de/en/
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.