Subject: Re: [sv-ec] Section 12.6.4 - wait
From: Stefen Boyd (stefen@boyd.com)
Date: Fri Feb 07 2003 - 09:12:33 PST
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 (408)739-1402 (fax)
This archive was generated by hypermail 2b28 : Fri Feb 07 2003 - 09:13:05 PST