Subject: RE: [sv-ec] Section 12.6.4 - wait
From: Jay Lawrence (lawrence@cadence.com)
Date: Sat Feb 08 2003 - 15:34:37 PST
> As for Jay's non-blocking events. They are a cute idea, and I have no
objection
> if someone makes a proposal to add them to the language.
Incidentally, these
> non-blocking events can be easily emulated using non-blocking
assignments to
> a bit.
Note that named events could also be implemented via the following but
were not.
reg event_bit;
....
event_bit = 1'b1;
#0 event_bit = 1'b0;
....
The triggering operator came into effect to avoid this.
===================================
Jay Lawrence
Architect - Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
-----Original Message-----
From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Saturday, February 08, 2003 6:26 PM
To: sv-ec@eda.org
Subject: Re: [sv-ec] Section 12.6.4 - wait
Stefen,
I believe that our positions are by now clear.
As currently defined, an 'event bit' is indeed a self-resetting bit,
which in
my mind is an event with an observable triggered state. Conceptually, I
don't see the difference between 'event bit' and a traditional Verilog
event.
Both events self-reset themselves; the Verilog event resets itself it at
the
time that it's triggered, whereas the persistent event does so at the
end
of the time step. But, because the triggered state of the traditional
event
is not observable, simulators don't actually maintain such a state.
If there existed a syntax that could wakeup a process at read-only-synch
and it allowed changing the state of an event bit at that time then yes,
your
sample code would be equivalent to the 'event bit' triggering semantics
(I'm
not disagreeing with you on this). However, assignments are not allowed
during read-only-synch, which is why the 'event bit' semantics can only
be
safely implemented inside the simulation kernel.
I also see where you are coming from and I appreciate your point about
extending @ to handle persistent events. However, I feel that changing
(or
extending) the event control operator to behave like another existing
operator
(wait) is unwarranted. Surely, it can be made to work, but the
definition of @
would have to be something like 'the event control is edge-sensitive
except when
any of its arguments is an event-bit, in which case it is
level-sensitive and behaves
like a wait...'. I think that this gets even more confusing if the
event operator is
overloaded in this manner, and then modified to accommodate the
wait-all/order
semantics. Then, users would never be able to wait for the edge of a
persistent
event. Currently, @ and wait allow for either behavior and we're
suggesting that
SystemVerilog doesn't change that. Perhaps we can poll committee
members
to get everyone's opinion on this.
As for Jay's non-blocking events. They are a cute idea, and I have no
objection
if someone makes a proposal to add them to the language. Incidentally,
these
non-blocking events can be easily emulated using non-blocking
assignments to
a bit. However, it should be clear to everyone that we are talking
about two very
different beasts to solve a similar problem. Non-blocking events might
eliminate
some races, but they will NOT solve all such races; the persistent event
will.
Arturo
----- Original Message -----
From: Stefen Boyd <mailto:stefen@boyd.com>
To: Arturo Salz <mailto:Arturo.Salz@synopsys.COM>
Cc: sv-ec@eda.org
Sent: Friday, February 07, 2003 9:12 AM
Subject: Re: [sv-ec] Section 12.6.4 - wait
Arturo,
It looks like at the very least, major clarification of
a persistent event is required. From what I see here, you
are saying that 'event bit' is really just a bit that resets
at the end of the timestep... That is not what is communicated
from the section. This shouldn't be called a persistent event,
it should be called a self-resetting bit. It's just a matter
of convenience that you can use event trigger syntax to set
it.
Assuming that ##0 gets you to cbAtEndOfSimTime (from the hdlcon
paper on pli callbacks), you are suggesting that:
event bit foo;
initial #100 ->foo;
would be equivalent to:
bit foo = 0;
always @(posedge foo) foo <= ##0 0;
initial #100 foo = 1;
I had instead assumed that it was in fact an event, and should
be treated as an event. I expected to be able to change the event
to the new event type if I was having trouble with triggering
events before I made it to my event control (while in the same
timestep). The thought was this is something that extends an event
so I can simply change my event type and PRESTO! I've got my problem
solved. If I have to rewrite *all* my code, I don't see the benefit.
In fact, the non-blocking event is starting to sound like a much
better idea. At least with that, all I have to do is use a different
trigger ('->>') and PRESTO! my race is fixed, just like NBAs fix
races with my RTL.
The alternative is not to change the event control to wait
semantics! I would never suggest we should kill existing code.
But if we view an 'event bit' as a special *event*, rather than
a special bit, we can make event control handle the special
*event* the same as the wait, now we have something valuable.
Existing events are handled just as before, and this new *event*
is handled in the way one would expect an event to be handled -
with event control!
We need to either choose nonblocking events or make the persistent
event work with event control (i.e. triggering earlier in
same timestep before '@' activation is the same as triggering
after '@' activation).
Stefen
At 05:52 PM 2/6/2003 -0800, Arturo Salz wrote:
I think that the confusion is cleared up when you consider that
the @ operator is "edge sensitive", and therefore always blocks.
For example,
@(posedge b) @(posegde b) $display( "done" );
Will block until 2 posedge transitions on b.
The wait construct, however, is "level sensitive" and has the correct
semantics to deal with persistent events (i.e. levels).
If we re-design @ to become wait semantics then a lot of
existing code will break. We tried to avoid doing any such major
redesign around exciting language features. This is why the
wait_all/wait_any/... calls take on the wait form.
You are correct that if a user wrote @ and later decided that what
was needed is wait then all those @'s would have to be changed.
However, I'd suggest that an 'event bit' is different from an 'event'
and, therefore, that is the current situation. If a user changes the
type of a variable from event to reg, the same exact changes would
be required. The persistent event simply adds the capability of
automatically resetting itself at the end of the time step.
--------------------
Stefen Boyd Boyd Technology, Inc.
stefen@BoydTechInc.com (408)739-BOYD
www.BoydTechInc.com <http://www.boydtechinc.com/>
(408)739-1402 (fax)
This archive was generated by hypermail 2b28 : Sat Feb 08 2003 - 15:36:01 PST