Subject: Re: [sv-ec] Comments on event changes CH17.html
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Jan 09 2003 - 15:27:39 PST
> From Arturo.Salz@synopsys.com Thu Jan 9 14:53:01 2003
>
> Kevin,
>
> With the @<event>.active syntax your are proposing several things:
>
> 1) A new syntax change.
What you're proposing also involves syntax changes, so that's a null argument.
> 2) A new method? or property: active.
It's most like a VHDL implicit signal, e.g. <signal>'active.
> 3) That the persistent state be determined by the form of the @ statement
Not really, the fact that it is active is just a property of the event.
> By making persistency dependent on the form of the @ statement , you force
> the compiler to analyze all the code for any usage of a particular event in order
> to determine the persistency. In the face of event variables and event arguments
> this requires a complex data-flow analysis that may not always give a definitive
> answer. It also creates an ambiguity when the same event is used or appears to
> be used in both a persistent and a non-persistent context. These are some of the
> reasons we decided to make persistency an explicit event type.
From an implementation perspective you just tag the event with the time it fired
and any "@<event>.active" for the same time evaluates true.
Seems like simple unambiguous behavior to me.
> Also, we proposed the wait( event ) statement, which is existing SystemVerilog,
> be used to wait for a persistent event. The reason for this is that the @ statement
> is always a blocking statement whereas wait is not (like persistent semantics).
> Changing @ to become non-blocking in some contexts is very un-Verilog like and
> will unduly complicate code generation.
A lot of what is being added is un-Verilog like. At least "<event>.active" looks
like something from another HDL.
You could use ".active" on signals as well as events.
Kev.
>
> Arturo
>
> ----- Original Message -----
> From: "Kevin Cameron x3251" <Kevin.Cameron@nsc.com>
> To: <lawrence@cadence.com>; <sv-ec@eda.org>; <Arturo.Salz@synopsys.COM>
> Sent: Thursday, January 09, 2003 2:28 PM
> Subject: Re: [sv-ec] Comments on event changes CH17.html
>
>
> > From: "Arturo Salz" <Arturo.Salz@synopsys.com>
> >
> > Jay,
> >
> > You are correct to state that the LRM needs to specify the point in
> > the Verilog simulation cycle in which persistent events change back
> > to the "off" state. However, I do not believe that we need to add yet
> > another item to the stratified event queue. It's perfectly OK to reset
> > events during read-only-synchronize (at the same time as monitor
> > events). This is because only the positive edge (off -> on transition)
> > is visible outside the simulation kernel. A process can't be sensitive
> > to the "off" transition so the reset is akin to the monitor list update.
> > I assumed that this was implied from the language "until simulation
> > time advances", but it would be good to state it explicitly.
> >
> > I appreciate what you are trying to do with the "non-blocking event trigger".
> > Your proposal is in fact similar to the original Vera functionality in which
> > the "persistency" of an event was a function of the trigger function. That
> > functionality was changed to facilitate event management in Verilog by
> > making the persistency an explicit part of the event.
> >
> > Unfortunately, your proposal doesn't solve the problem, it merely reduces
> > the likelihood of its occurrence when the expects (@) execute at the same
> > time as blocking assignments. This precludes deterministic operation of
> > processes that are both sensitive to as well as trigger events, since that
> > might lead to multiple NBA times. Your message acknowledges this fact,
> > and states that it very rarely is a problem. But, events are used primarily
> > for verification, and verification code executes during the "verification phase",
> > which takes place after all non-blocking assignments, thus, your proposal
> > might simply exacerbate the existing non-determinism problem by adding
> > the scheduling or processing order of non-blocking events to the equation.
> > The bottom line is that if the triggered state of an event does not persist
> > throughout the time step, the problem reappears.
> >
> > For example, consider the following example:
> >
> > event E1, E2;
> > fork
> > T1: begin @ E1 ; @ E2; end
> > T2: ->> E2;
> > T3: ->> E1;
> > join
> >
> >
> > Depending on the scheduling order of event triggering, the first process, T1,
> > will either unblock or block forever. If this is rewritten with persistent events
> > then regardless of the scheduling order, T1 always unblocks. Many other
> > simple examples will work deterministically with persistent events but will
> > exhibit scheduling order dependencies using non-blocking event triggers.
>
> I'd still rather go with something like:
>
> event E1, E2;
> fork
> T1: begin @ E1.active ; @ E2.active ; end
> T2: -> E2;
> T3: -> E1;
> join
>
> <event>.active becomes true when <event> fires and stays true until time
> advances.
>
> It is more obvious what's going on at T1 when the declarations and triggers
> are not visible to a user reading the code, and doesn't need a new event type
> or trigger operator.
>
> Kev.
>
>
>
> > Finally, I'd like to clarify something about your example. The example does
> > capture the gist of the problem (the lack of determinism due to scheduling
> > order) that motivates persistent events, and it is strictly correct since the V2K
> > LRM does not explicitly specify the execution order of processes within a
> > fork..join. However, all Verilog implementations of which I'm aware do execute
> > the processes in source-order (T1, T2, T3 in the example). As a result, the
> > outcome will always be to display "T1". I simply wanted to clarify this in case
> > someone tries the example and deems this not to be a problem due to the
> > inherent determinism of existing implementations. I added a paragraph to
> > this effect in the 3.1 LRM (see section 9.7) since I believe that specifying the
> > order provides for better cross-tool determinism (and this is the de-facto way
> > in which all vendors implement fork..join).
> >
> > Arturo
> >
> > ----- Original Message -----
> > From: "Jay Lawrence" <lawrence@cadence.com>
> > To: <sv-ec@eda.org>
> > Sent: Monday, January 06, 2003 3:47 AM
> > Subject: [sv-ec] Comments on event changes CH17.html
> >
> >
> >
> > I assume we are going to begin today where we left off on the event
> > debate. I believe the debate now focuses more around the contents of
> > http://www.eda.org/sv-ec/CH17.html than what is in the Draft 1 LRM so my
> > comments refer to that document.
> >
> > Syntax nits
> > ----------
> >
> > - It currently says:
> >
> > > The syntax to declare a non-persistent event is:
> > > event event_dentifier;
> >
> > I believe this should be 'event_identifier' this occurs a bunch of times
> > in the changes document.
> >
> > - last example is:
> >
> > > fork
> > > T1: while(1) @ E2;
> > > T2: while(1) @ E1;
> > > T3: begin
> > > E2 = E1;
> > > while(1) -> E2);
> > > end
> > >join
> >
> > The line "while(1) -> E2);" has a syntax error, the last ')' is not
> > needed.
> > This would also send NC into an infinite loop forever triggering E2. It
> > think the entire line should just be '-> E2;' and remove the while
> > altogether (maybe it needs a begin/end).
> >
> >
> > Persistent Event Clarification Needed
> > -------------------------------------
> >
> > If we are going to accept this concept of an event that "persists
> > throughout the time-step, that is, until simulation time advances". We
> > are going to need to propose a change in the simulation cycle (1364 -
> > Chapter 5) to add a portion of the stratified event queue where these
> > things change state back to "off" after the monitor events have
> > executed.
> >
> >
> > Alternative Proposal for "Persistent Event" - "Non-blocking Event
> > Trigger"
> > ------------------------------------------------------------------------
> > --
> >
> > Note: this is different than what Adam K. previously proposed (and was
> > rejected)in IEEE 1364, that was events with transport delays, but had
> > the same title.
> >
> > The big value added by the persistent event is the reduced
> > non-determinism created by allowing the event to remain triggered in
> > order to avoid race conditions which occur from 0-delay simulation
> > semantics. This is exactly like the race-conditions that are created by
> > using blocking assignments.
> >
> > I propose the we introduce a new operator ->> which we will call the
> > non-blocking trigger operator. The operator takes a single event as an
> > argument:
> > event E;
> >
> > ->> E;
> >
> > The effect of this operator is that the event E will be triggered in the
> > non-blocking assignment phase of the simulation cycle. In 1364, this
> > would be defined as adding a "non-blocking assign update event" to the
> > current simulation time. The effect of this update event would be to
> > trigger the referenced event.
> >
> > The procedural code context in which the non-blocking trigger occurs
> > continues to execute sequentially (does not block). This is also true of
> > the regular trigger '->' operator, so the name non-blocking event
> > trigger refers to when the event is scheduled rather than what happens
> > in the sequential context.
> >
> > This delaying of the event trigger until NBA-time disambiguates the
> > triggering of events in exactly the same way that non-blocking
> > assignments disambiguated assignment many years ago, and requires no
> > changes to the simulation cycle.
> >
> > It also has the advantage that events do not have to take on the
> > characteristic of having a persistent value over time. They are still
> > just instantaneously triggered (like the (posedge clk) in the CH17
> > proposal), so a new declaration for events (event bit) is not necessary.
> > All events could be triggered in this way. Note, I actually like the
> > promotion of events to first class objects that can be assigned to one
> > another and passed to tasks. I would even allow them to occur in
> > 'struct' and 'union' objects to embed an event with data.
> >
> > The following example is ambiguous.
> >
> > event E1;
> > fork
> > T1: begin @ E1 $display("T1"); end;
> > T2: -> E1
> > T3: begin @ E1 $display("T3"); end;
> > join
> >
> > Depending on the simulator (or even simulation cycle) Either T1 or T3,
> > or both will display and the fork/join may or may not ever unblock. If
> > you replace the trigger with a non-blocking trigger.
> >
> > event E1;
> > fork
> > T1: begin @ E1 $display("T1"); end;
> > T2: ->> E1
> > T3: begin @ E1 $display("T3"); end;
> > join
> >
> > The order of execution becomes unimportant. T1 and T3 would both block
> > and the trigger would be scheduled for NBA-time. When NBA-time arrives,
> > both processes would always see the event.
> >
> > There of course remain multiple NBA times possible in a given simulation
> > cycle, but that very, very rarely causes issues with blocking vs.
> > non-blocking assignment ambiguity. This solves the race condition
> > problem triggering events with no more and no less ambiguity than
> > non-block assignments did without introducing a new class of object or
> > changing the simulation cycle.
> >
> > Note, a logical extension of this proposal would also be to allow a
> > delay control after the operator:
> > ->> #5 E1;
> > I bring it up here just because someone will. I think it makes sense but
> > wouldn't protest too hard if only the immediate case was allowed. This
> > is closer to Adam's proposal on adding transport delays to event
> > triggering.
> >
> > Jay
> >
> >
> >
> >
> >
> >
>
>
>
>
>
This archive was generated by hypermail 2b28 : Thu Jan 09 2003 - 15:28:57 PST