Subject: RE: [sv-ec] Comments on event changes CH17.html
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Jan 09 2003 - 18:08:38 PST
----------
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>
end<BR>>join<BR><BR>The line "while(1) -> E2);" has a syntax =
triggered in<BR>order to avoid race conditions which occur from =
non-blocking<BR>assignments disambiguated assignment many years ago, =
This archive was generated by hypermail 2b28
: Thu Jan 09 2003 - 18:09:31 PST
<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>> =
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 =
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 =
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></BLOCKQUOTE></FON=
T></BODY></HTML>