Subject: Re: [sv-ec] Comments on event changes CH17.html
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Jan 09 2003 - 14:28:57 PST
> 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 - 14:29:39 PST