For this committee we should focus on the language definition and required semantics and behavior.
I believe there is general consensus that we treat the current behavior as a bug which we fix, to match Verilog semantics.
I am not in favor of adding a requirement that compliant implementations must detect and diagnose code that would behave differently given this change.
I believe many users are unaware and would be surprised by the current behavior (witness the subject of this thread). To subject such users who during the life of this revision of the standard, say in 2014 first write code that today would fall into this trap to a message that tells them that by the way their code would have run differently in an older simulator seems unuseful.
Implementations of a compliant simulator(commercial or proof of concept) are of course free to add such useful debugging and version-sensitive model detection logic, perhaps under configuration switches and the like; or to focus on delivering to the user the fastest performance.
In my opinion this committee should not mandate such choices.
Mac
________________________________
From: owner-systemc-p1666-technical@eda.org <owner-systemc-p1666-technical@eda.org>
To: Bishnupriya Bhattacharya
Cc: David Black <dcblack@xtreme-eda.com>; Philipp A Hartmann <philipp.hartmann@offis.de>; P1666 Technical WG <systemc-p1666-technical@eda.org>
Sent: Wed Jan 19 11:01:15 2011
Subject: RE: P1666 surprising result with immediate notification
Bishnupriya,
I agree with you technically, but I was making a slightly different compromise. My thoughts were that the PoC simulator should keep its current bad behavior for the time being for backward compatibility, but that immediate self-notification should be deprecated in order to discourage applications from doing it. The compromise I am making is that in some future version of SC a process might actually be forbidden from making an immediate notification to an event to which it is statically sensitive or following next_trigger, rather than the notification simply doing nothing. If that is not acceptable, then my proposal collapses.
Personally I would also be okay with straight "Verilog semantics", meaning that an immediate self-notification would do nothing (not deprecated, no warning), and live with the possibility of backward incompatibilities.
John A
-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, David Black <dcblack@xtreme-eda.com>, Philipp A Hartmann <philipp.hartmann@offis.de>, P1666 Technical WG <systemc-p1666-technical@eda.org>
From: Bishnupriya Bhattacharya <bpriya@cadence.com>
Date: 01/19/2011 05:29PM
Subject: RE: P1666 surprising result with immediate notification
John,
I agree with the Verilog semantics, but am not sure of the means to achieve that. You say
“Deprecating any immediate notification of an event to which the calling process is statically sensitive or already sensitive using next_trigger”
This does not seem right to me. Rather the immediate notifications as above should be valid, but will not have any effect in terms of rescheduling the process in the current eval. An implementation can issue a warning in these cases if it wants – of the nature that behavior has changed, these notifications will no longer have any effect on scheduling the currently executing process.
Otherwise we will have the sitn. that a process that is statically sensitive to an event, and also immediately notifies that event to trigger ANOTHER process will start getting this warning stating it is doing something wrong, which it is not. The problem is not with the process immediately notifying the event, but with the implementation wrongly interpreting that to schedule the currently executing process.
Thoughts?
Thanks,
-Bishnupriya
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Wednesday, January 19, 2011 3:26 PM
To: David Black; Philipp A Hartmann; Bishnupriya Bhattacharya; P1666 Technical WG
Subject: RE: P1666 surprising result with immediate notification
All,
One plank of SystemC is the co-routine semantics. The more I think about it, the more I think that the PoC behavior is an anomaly. A running process should not notice an immediate notification to itself.
I would vote for
* Keeping the PoC behavior as it is (for backward compatibility)
* Deprecating any immediate notification of an event to which the calling process is statically sensitive or already sensitive using next_trigger.
* An immediate notification of an event to which the calling process is not statically sensitive but is subsequently made sensitive using wait(ev) or next_trigger(ev) is permitted
* (With an OSCI hat on) Adding a warning to the PoC sim to cover the deprecated cases (is that too expensive?)
(IMHO adding a method by which a process can immediately notify itself is not such a good idea, unless some compelling use case emerges)
Does that work?
John A
From:
Bishnupriya Bhattacharya <bpriya@cadence.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>
Cc:
David Black <dcblack@xtreme-eda.com>, Philipp A Hartmann <philipp.hartmann@offis.de>, P1666 Technical WG <systemc-p1666-technical@eda.org>
Date:
19/01/2011 03:51
Subject:
RE: P1666 surprising result with immediate notification
________________________________
John,
I had exactly the same assumption as you until I discovered certain anomalies in the process control work. Personally, I would be happiest with the Verilog rules, which only differs from my rules in that a next_trigger for a method process takes effect immediately rather than waiting for the method to return. But I worry about backwards compatibility. If we can work something out (perhaps along the lines of what Philipp suggests in a subsequent email) whereby we can both clean up the semantics as well as maintain a backward compatibility hook, that might be the right way to go both philosophically and pragmatically.
I also agree with Tor about self-triggering processes being a nuisance in parallel implementations.
Thanks,
-Bishnupriya
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Wednesday, January 19, 2011 12:56 AM
To: Bishnupriya Bhattacharya
Cc: David Black; Philipp A Hartmann; P1666 Technical WG
Subject: RE: P1666 surprising result with immediate notification
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.
Greetings from Oldenburg,
Philipp
On 17/01/11 11:16, Jerome CORNET wrote:
[snip]
>
> *From:*owner-systemc-p1666-technical@eda.org
> [mailto:owner-systemc-p1666-technical@eda.org] *On Behalf Of *David C Black
> *Sent:* Wednesday, December 15, 2010 10:11 PM
> *To:* P1666 Technical WG
> *Subject:* Fwd: P1666 surprising result with immediate notification
>
> [...]
>
> I see this is specified in the standard, but I contend it is very
> confusing and non-intuitive. Interestingly, *if you reverse the process
> registrations, the repetition goes away.* I imagine this could lead to
> some very hard to debug problems. Of course I routinely advise students
> to be careful with immediate notifications, but perhaps caution is not
> enough...
>
>
> [JC] Here what is the most confusing for me is the dependency on the
> process order registration... Either it should work whatever the order,
> or it should not work, but not a mix.
>
> My expectation was that *sc_event*::*notify*(*void*) would only affect
> those processes that are already have executed some form of *wait()* (or
> returned in the case of *SC_METHOD*). My internalized understanding of
> "static sensitivity" is that it is a sensitivity list created during
> elaboration and unable to change after that. The
> *sc_event*::*wait*(*void*) method is simply an *SC_THREAD*'s way of
> dynamically waiting on the statically specified list.
>
>
> [JC] Here I have to admit that I never fully understood the static
> sensitive thing. In my own way of thinking:
>
> SC_THREAD(ex2_thread1);
> sensitive << event;
>
> void ex2_thread1()
> {
> [...]
> wait();
> [...]
> }
>
> should be equivalent to:
>
> SC_THREAD(ex2_thread1);
>
> void ex2_thread1()
> {
> [...]
> wait(event);
> [...]
> }
>
> so I find very strange that the behavior of a process with respect to
> immediate notification differs depending on the way
> you actually wait for the event.
>
> Admittedly, it is problematic coding to have a process wait an event
> like this.
>
> Should the above behavior be allowed?
>
> Why does it happen (what is the mechanism)?
>
> Perhaps more importantly:
>
> * Is this behavior expected?
> * Is there a good application of this behavior?
> * Is this unavoidable?
>
> [JC] I won’t say that using this is proper coding or whatever, but I
> have already seen a somewhat “good” application of “this behavior” (by
> “this behavior”
>
> I mean: “a process can notify immediately an event, then wait() for it
> just after that and be predictably awaken in the same evaluation phase
> whatever the process declaration order is”).
>
> The application in question was the possibility to implement a pure
> “yield” in SystemC, for research purposes (but this can have
> applications for real platforms).
>
> A yield is a base construct in cooperative scheduling, that allows a
> process to relinquishes control to the scheduler. In SystemC, we don’t
> have “pure” yield
>
> constructs, in the sense that only wait() is doing such effect, and this
> is always associated with an event or a time. Sometimes, you just want
> the currently executing
>
> process to execute again in the very same evaluation phase “later” (that
> “later” can be “immediately” or after the last process or whatever).
>
> So the only way I know how to implement a pure yield() without modifying
> the kernel (and being out of the norm by the way), was the immediate
>
> notification-then-wait() trick.
>
>
> I don’t have a strong opinion, but I think that forbidding this practice
> or taking action so that it no longer work in subsequent SystemC
> versions would at least prevent people to emulate a pure yield() call.
> I concur with you that dependency on the process registration order
> in your example should not appear, and so if we choose to keep
> the behavior we would have to spell it more clearly and to have
> compliant implementations.
--
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.
=
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Jan 19 11:48:36 2011
This archive was generated by hypermail 2.1.8 : Wed Jan 19 2011 - 11:48:38 PST