Subject: RE: [sv-ec] Comments on event changes CH17.html
From: Jay Lawrence (lawrence@cadence.com)
Date: Thu Jan 09 2003 - 18:33:57 PST
As I said in the original proposal, I think a delay after the operator
is a good addition. I would want a new operator to make the different
behavior more explicit and operators don't conflict the way keywords do.
I think it was Adam that also suggested => instead of ->>. It's a toss
up....
Jay
P.s. You idea of adding something akin to signal valued attributes is
interesting for the persistent event case and is useful elsewhere. It
does differ significantly from VHDL signal-valued attributes because
without a parameter they only stay true for one simulation cycle.
> -----Original Message-----
> From: Kevin Cameron x3251 [mailto:Kevin.Cameron@nsc.com]
> Sent: Thursday, January 09, 2003 9:09 PM
> To: Arturo.Salz@synopsys.com; sv-ec@eda.org; Jay Lawrence
> Subject: RE: [sv-ec] Comments on event changes CH17.html
>
>
> ----------
> X-Sun-Data-Type: text
> X-Sun-Data-Description: text
> X-Sun-Data-Name: text
> X-Sun-Charset: us-ascii
> X-Sun-Content-Lines: 289
>
> > From: "Jay Lawrence" <lawrence@cadence.com>
> >
> > Thanks for the reply Arturo,
> >
> > I think the non-blocking trigger operator is a good solid
> addition to
> > 1364 independent of the semantics you propose. I will move
> in the next
> > (voting) sv-ec meeting that we adopt the non-blocking
> trigger operator
> > independent of anything around persistent triggers. They can be
> > considered independently.
>
> Since that would introduce scheduling on events, how about
> just putting
> a delay after the current operator? E.g. "->> E" becomes:
>
> -> #0 E;
>
> You could do arbitrary delays too.
>
> Kev.
>
>
> > Your argument that the non-blocking event trigger exacerbates the
> > non-determinism problem when they are used during the proposed
> > "verification phase" may be a problem of a verification phase
> > interacting with a complete simulation cycle. The
> verification phase is
> > as yet not fully explained, and Peter's explanation at the last
> > face-to-face left a lot of questions in my mind. If you'll
> remember my
> > comments at the time, the diagrams showed clock-cycles and
> simulation
> > cycles interchangeably and the sub-simulation cycle event
> issues were
> > not addressed at all. I believe others had similar questions. The
> > ordering of design -> clock -> verification -> assertion was very
> > controversial.
> >
> > If the rationale for persistent events involves adopting the as yet
> > unadopted topics of clock domains and the verification
> phase, then we
> > may have to postpone the decisions on persistent events
> until we reach
> > those areas of the donations. Similar to the way we have postponed
> > classes in Chapter 3 until Chapter 11.
> >
> > Jay
> >
> >
> > -----Original Message-----
> > From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> > Sent: Thursday, January 09, 2003 5:00 PM
> > To: Jay Lawrence; sv-ec@eda.org
> > Subject: Re: [sv-ec] Comments on event changes CH17.html
> >
> >
> >
> > 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.
> >
> > 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" < <mailto:lawrence@cadence.com>
> > lawrence@cadence.com>
> > To: < <mailto:sv-ec@eda.org> 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>
> 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
> >
> >
> >
> >
> >
> >
> >
>
> ----------
> X-Sun-Data-Type: html
> X-Sun-Encoding-Info: quoted-printable
> X-Sun-Content-Lines: 383
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dus-ascii">
> <TITLE>Message</TITLE>
>
> <META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY>
> <DIV><SPAN class=3D662343601-10012003><FONT face=3DArial
> size=3D2>Thanks =
> for the reply=20
> Arturo,</FONT></SPAN></DIV>
> <DIV><SPAN class=3D662343601-10012003><FONT face=3DArial=20
> size=3D2></FONT></SPAN> </DIV>
> <DIV><SPAN class=3D662343601-10012003><FONT face=3DArial size=3D2>I =
> think the=20
> non-blocking trigger operator is a good solid addition to 1364 =
> independent of=20
> the semantics you propose. I will move in the next (voting) sv-ec =
> meeting that=20
> we adopt the non-blocking trigger operator independent of anything =
> around=20
> persistent triggers. They can be considered =
> independently.</FONT></SPAN></DIV>
> <DIV><SPAN class=3D662343601-10012003><FONT face=3DArial=20
> size=3D2></FONT></SPAN> </DIV>
> <DIV><SPAN class=3D662343601-10012003><FONT face=3DArial
> size=3D2>Your =
> argument that=20
> the non-blocking event trigger exacerbates the
> non-determinism problem =
> when they=20
> are used during the proposed "verification phase" may be a
> problem of a=20
> verification phase interacting with a complete simulation =
> cycle. The=20
> verification phase is as yet not fully explained, and Peter's =
> explanation=20
> at the last face-to-face left a lot of questions in my mind.
> If you'll =
> remember=20
> my comments at the time, the diagrams showed clock-cycles and
> simulation =
> cycles=20
> interchangeably and the sub-simulation cycle event issues were not =
> addressed at=20
> all. I believe others had similar questions. The ordering of design =
> -> clock=20
> -> verification -> assertion was very =
> controversial.</FONT></SPAN></DIV>
> <DIV><SPAN class=3D662343601-10012003><FONT face=3DArial=20
> size=3D2></FONT></SPAN> </DIV>
> <DIV><SPAN class=3D662343601-10012003><FONT face=3DArial
> size=3D2>If the =
> rationale for=20
> persistent events involves adopting the as yet unadopted
> topics of clock =
> domains=20
> and the verification phase, then we may have to postpone the
> decisions =
> on=20
> persistent events until we reach those areas of the
> donations. Similar =
> to the=20
> way we have postponed classes in Chapter 3 until Chapter =
> 11.</FONT></SPAN></DIV>
> <DIV><SPAN class=3D662343601-10012003><FONT face=3DArial=20
> size=3D2></FONT></SPAN> </DIV>
> <DIV><SPAN class=3D662343601-10012003><FONT face=3DArial=20
> size=3D2>Jay</FONT></SPAN></DIV>
> <DIV><SPAN class=3D662343601-10012003><FONT face=3DArial=20
> size=3D2></FONT></SPAN> </DIV>
> <BLOCKQUOTE=20
> style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT:
> #000000 2px =
> solid; MARGIN-RIGHT: 0px">
> <DIV></DIV>
> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
> align=3Dleft><FONT=20
> face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
> Arturo Salz=20
> [mailto:Arturo.Salz@synopsys.com] <BR><B>Sent:</B>
> Thursday, January =
> 09, 2003=20
> 5:00 PM<BR><B>To:</B> Jay Lawrence;
> sv-ec@eda.org<BR><B>Subject:</B> =
> Re:=20
> [sv-ec] Comments on event changes CH17.html<BR><BR></FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2>
> <DIV><FONT face=3DArial size=3D2>Jay,</FONT></DIV><FONT
> face=3DArial =
> size=3D2>
> <DIV><BR>You are correct to state that the LRM needs to
> specify the =
> point=20
> in</DIV>
> <DIV>the Verilog simulation cycle in which persistent
> events change =
> back</DIV>
> <DIV>to the "off" state. However, I do not believe
> that we need =
> to add=20
> yet</DIV>
> <DIV>another item to the stratified event queue. It's
> perfectly =
> OK to=20
> reset</DIV>
> <DIV>events during read-only-synchronize (at the same time as =
> monitor</DIV>
> <DIV>events). This is because only the positive edge
> (off -> =
> on=20
> transition)</DIV>
> <DIV>is visible outside the simulation kernel. A
> process can't =
> be=20
> sensitive</DIV>
> <DIV>to the "off" transition so the reset is akin to the
> monitor list=20
> update.</DIV>
> <DIV>I assumed that this was implied from the language "until =
> simulation</DIV>
> <DIV>time advances", but it would be good to state it =
> explicitly.</DIV>
> <DIV></FONT><FONT face=3DArial size=3D2><BR>I appreciate
> what you are =
> trying to do=20
> with the "non-blocking event trigger".<BR>Your proposal is in fact =
> similar to=20
> the original Vera functionality in which<BR>the
> "persistency" of an =
> event was=20
> a function of the trigger function. That</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>functionality was changed to =
> facilitate event=20
> management in Verilog by</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>making the persistency an =
> explicit part=20
> of the event.<BR><BR>Unfortunately, your proposal doesn't
> solve the =
> problem,=20
> it merely reduces</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>the likelihood of its
> occurrence when =
> the expects=20
> (@) execute at the same</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>time as </FONT><FONT face=3DArial =
> size=3D2>blocking=20
> assignments. This precludes deterministic operation =
> of</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>processes that are both
> sensitive to =
> as well as=20
> trigger events, since that</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>might </FONT><FONT face=3DArial =
> size=3D2>lead=20
> </FONT><FONT face=3DArial size=3D2>to multiple NBA
> times. Your =
> message=20
> acknowledges this fact,</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>and states that it very
> rarely is a=20
> problem. But, events are used primarily</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>for verification, and
> verification =
> code executes=20
> during the </FONT><FONT face=3DArial size=3D2>"verification=20
> phase",</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>which takes place </FONT><FONT =
> face=3DArial=20
> size=3D2>after all non-blocking assignments, thus, your =
> proposal</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>might simply exacerbate
> the existing =
> </FONT><FONT=20
> face=3DArial size=3D2>non-determinism problem by adding</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>the scheduling or
> processing order of =
>
> non-blocking events to the equation.</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>The bottom </FONT><FONT
> face=3DArial =
> size=3D2>line is=20
> that if the triggered state </FONT><FONT face=3DArial
> size=3D2>of an =
> event does=20
> not persist</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>throughout the time step,
> the problem =
>
> reappears.</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
> <DIV><FONT face=3DArial size=3D2>For example, consider the
> following=20
> example:<BR><BR> event E1, E2;</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>
> fork</FONT></DIV>
> <DIV><FONT face=3DArial =
> size=3D2> T1:=20
> begin @ E1 ; @ E2; =
> end<BR> T2:=20
> ->> E2;<BR> T3: =
> ->>=20
> E1;<BR> join<BR></FONT><FONT face=3DArial =
> size=3D2></FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
> <DIV><FONT face=3DArial size=3D2>Depending on the
> scheduling order of =
> event=20
> triggering, the first process, T1,</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>will either unblock or block =
> forever. If=20
> this is rewritten with persistent events=20
> <DIV><FONT face=3DArial size=3D2>then regardless of the scheduling =
> order, T1=20
> always unblocks. Many other=20
> <DIV><FONT face=3DArial size=3D2>simple examples will work =
> deterministically with=20
> persistent events but will</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>exhibit scheduling order
> dependencies =
> using=20
> non-blocking event triggers.</FONT></DIV>
> <DIV> </DIV>
> <DIV>Finally, I'd like to clarify something about your
> example. =
> The=20
> example does</DIV>
> <DIV>capture the gist of the problem (the lack of
> determinism due to=20
> scheduling</DIV>
> <DIV>order) that motivates persistent events, and it is strictly =
> correct since=20
> the V2K</DIV>
> <DIV>LRM does not explicitly specify the execution order of
> processes =
> within=20
> a</DIV>
> <DIV>fork..join. However, all Verilog implementations
> of which =
> I'm aware=20
> do execute</DIV>
> <DIV>the processes in source-order (T1, T2, T3 in the
> example). =
> As a=20
> result, the</DIV>
> <DIV>outcome will always be to display "T1". I simply
> wanted to =
> clarify=20
> this in case</DIV>
> <DIV>someone tries the example and deems this not to be a
> problem due =
> to=20
> the</DIV>
> <DIV>inherent determinism of existing
> implementations. I added a =
>
> paragraph to</DIV>
> <DIV>this effect in the 3.1 LRM (see section 9.7) since I
> believe that =
>
> specifying the</DIV>
> <DIV>order provides for better cross-tool determinism (and
> this is the =
>
> de-facto way</DIV>
> <DIV>in which all vendors implement=20
> fork..join).</DIV></FONT></DIV></FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></FONT></DIV>
> <DIV><FONT face=3DArial size=3D2> =
> Arturo</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
> <DIV><FONT face=3DArial size=3D2>----- Original Message ----- =
> </FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>From: "Jay Lawrence"
> <</FONT><A=20
> href=3D"mailto:lawrence@cadence.com"><FONT face=3DArial=20
> size=3D2>lawrence@cadence.com</FONT></A><FONT face=3DArial=20
> size=3D2>></FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>To: <</FONT><A=20
> href=3D"mailto:sv-ec@eda.org"><FONT face=3DArial=20
> size=3D2>sv-ec@eda.org</FONT></A><FONT face=3DArial =
> size=3D2>></FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>Sent: Monday, January 06,
> 2003 3:47=20
> AM</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>Subject: [sv-ec] Comments
> on event =
> changes=20
> CH17.html</FONT></DIV>
> <DIV><FONT face=3DArial><BR><FONT =
> size=3D2></FONT></FONT></DIV><BR><FONT=20
> face=3DArial size=3D2>I assume we are going to begin today
> where we =
> left off on=20
> the event<BR>debate. I believe the debate now focuses more
> around the =
> contents=20
> of<BR></FONT><A href=3D"http://www.eda.org/sv-ec/CH17.html"><FONT =
> face=3DArial=20
> size=3D2>http://www.eda.org/sv-ec/CH17.html></A><FONT =
> face=3DArial size=3D2>=20
> than what is in the Draft 1 LRM so my<BR>comments refer to that=20
> document.<BR><BR>Syntax nits<BR>----------<BR><BR>- It currently=20
> says:<BR><BR>> The syntax to declare a non-persistent event=20
> is:<BR>> event
> event_dentifier;<BR><BR>I believe =
> this=20
> should be 'event_identifier' this occurs a bunch of
> times<BR>in the =
> changes=20
> document.<BR><BR>- last example is:<BR><BR>> fork<BR>> T1: =
> while(1) @=20
> E2;<BR>> T2: while(1) @ E1;<BR>> T3: begin<BR>> E2 =3D =
> E1;<BR>>=20
> while(1) ->=20
> =
> E2);<BR>> &n
> bsp; =
>
> end<BR>>join<BR><BR>The line "while(1) -> E2);" has a syntax =
> error, the=20
> last ')' is not<BR>needed. <BR>This would also send NC into an =
> infinite loop=20
> forever triggering E2. It<BR>think the entire line should just be =
> '-> E2;'=20
> and remove the while<BR>altogether (maybe it needs a=20
> begin/end).<BR><BR><BR>Persistent Event Clarification=20
> Needed<BR>-------------------------------------<BR><BR>If
> we are going =
> to=20
> accept this concept of an event that "persists<BR>throughout the =
> time-step,=20
> that is, until simulation time advances". We<BR>are going
> to need to =
> propose a=20
> change in the simulation cycle (1364 -<BR>Chapter 5) to add
> a portion =
> of the=20
> stratified event queue where these<BR>things change state back to =
> "off" after=20
> the monitor events have<BR>executed.<BR><BR><BR>Alternative
> Proposal =
> for=20
> "Persistent Event" - "Non-blocking=20
> =
> Event<BR>Trigger"<BR>-----------------------------------------
> -----------=
> --------------------<BR>--<BR><BR>Note:=20
> this is different than what Adam K. previously proposed (and=20
> was<BR>rejected)in IEEE 1364, that was events with
> transport delays, =
> but=20
> had<BR>the same title.<BR><BR>The big value added by the
> persistent =
> event is=20
> the reduced<BR>non-determinism created by allowing the
> event to remain =
>
> triggered in<BR>order to avoid race conditions which occur from =
> 0-delay=20
> simulation<BR>semantics. This is exactly like the
> race-conditions that =
> are=20
> created by<BR>using blocking assignments.<BR><BR>I propose the we =
> introduce a=20
> new operator ->> which we will call
> the<BR>non-blocking trigger=20
> operator. The operator takes a single event as =
> an<BR>argument:<BR>event=20
> E;<BR><BR>->> E;<BR><BR>The effect of this operator
> is that the =
> event E=20
> will be triggered in the<BR>non-blocking assignment phase of the =
> simulation=20
> cycle. In 1364, this<BR>would be defined as adding a "non-blocking =
> assign=20
> update event" to the<BR>current simulation time. The effect
> of this =
> update=20
> event would be to<BR>trigger the referenced event.<BR><BR>The =
> procedural code=20
> context in which the non-blocking trigger occurs<BR>continues to =
> execute=20
> sequentially (does not block). This is also true of<BR>the regular =
> trigger=20
> '->' operator, so the name non-blocking event<BR>trigger
> refers to =
> when the=20
> event is scheduled rather than what happens<BR>in the sequential=20
> context.<BR><BR>This delaying of the event trigger until NBA-time=20
> disambiguates the<BR>triggering of events in exactly the
> same way that =
>
> non-blocking<BR>assignments disambiguated assignment many
> years ago, =
> and=20
> requires no<BR>changes to the simulation cycle. <BR><BR>It
> also has =
> the=20
> advantage that events do not have to take on
> the<BR>characteristic of =
> having a=20
> persistent value over time. They are still<BR>just instantaneously =
> triggered=20
> (like the (posedge clk) in the CH17<BR>proposal), so a new
> declaration =
> for=20
> events (event bit) is not necessary.<BR>All events could be
> triggered =
> in this=20
> way. Note, I actually like the<BR>promotion of events to
> first class =
> objects=20
> that can be assigned to one<BR>another and passed to tasks.
> I would =
> even allow=20
> them to occur in<BR>'struct' and 'union' objects to embed an event =
> with=20
> data.<BR><BR>The following example is ambiguous.<BR><BR>event=20
> E1;<BR>fork<BR>T1: begin @ E1 $display("T1"); end;<BR>T2: -> =
> E1<BR>T3:=20
> begin @ E1 $display("T3"); end;<BR> =20
> join<BR><BR>Depending on the simulator (or even simulation cycle) =
> Either T1 or=20
> T3,<BR>or both will display and the fork/join may or may not ever =
> unblock.=20
> If<BR>you replace the trigger with a non-blocking =
> trigger.<BR><BR>event=20
> E1;<BR>fork<BR>T1: begin @ E1 $display("T1"); end;<BR>T2:
> ->> =
> E1<BR>T3:=20
> begin @ E1 $display("T3"); end;<BR> =20
> join<BR><BR>The order of execution becomes unimportant. T1 and T3 =
> would both=20
> block<BR>and the trigger would be scheduled for NBA-time. When =
> NBA-time=20
> arrives,<BR>both processes would always see the
> event.<BR><BR>There of =
> course=20
> remain multiple NBA times possible in a given
> simulation<BR>cycle, but =
> that=20
> very, very rarely causes issues with blocking vs.<BR>non-blocking =
> assignment=20
> ambiguity. This solves the race condition<BR>problem
> triggering events =
> with no=20
> more and no less ambiguity than<BR>non-block assignments
> did without=20
> introducing a new class of object or<BR>changing the simulation=20
> cycle.<BR><BR>Note, a logical extension of this proposal
> would also be =
> to=20
> allow a<BR>delay control after the operator:<BR>->>
> #5 E1;<BR>I =
> bring it=20
> up here just because someone will. I think it makes sense =
> but<BR>wouldn't=20
> protest too hard if only the immediate case was allowed.
> This<BR>is =
> closer to=20
> Adam's proposal on adding transport delays to=20
> =
> event<BR>triggering.<BR><BR>Jay<BR><BR><BR><BR><BR><BR></BLOCK
> QUOTE></FON=
> T></BODY></HTML>
>
>
This archive was generated by hypermail 2b28 : Thu Jan 09 2003 - 18:34:40 PST