Subject: Re: [sv-ec] Section 12.6.4 - wait
From: Stefen Boyd (stefen@boyd.com)
Date: Mon Feb 10 2003 - 10:39:17 PST
Arturo,
My comments below.
At 03:26 PM 2/8/2003 -0800, Arturo Salz wrote:
>Stefen,
>
>I believe that our positions are by now clear.
>
Good. No use discussing things we don't understand!
>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 it's a self resetting bit, then it shouldn't be
called an event! The proposal should simply allow
the use of the event trigger on a bit, with the
characteristics of trigger setting value to one and
it auto-retting at the end of a timestep.
>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.
>
understood... I was just trying to make sure I was
completely clear on the way the proposal worked.
>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.
>
First, making event control treat a persistent event like
a wait would not mean "users would never be able to wait for
the edge of a persistent event." The only thing you wouldn't be
able to do is wait for two persistent events in one timeslice. But
your proposal doesn't allow that either!
Normally, there is a big difference between wait and event
control because variables used in the wait statement can
stay "true" (causing the wait to unblock) for multiple
simulation tics.
Since this new kind of bit can't stay true for multiple
simulation tics, then there is no difference between the
use of wait or event control when a persistent event has
not yet been triggered. Once the event is triggered,
the wait and event control will both unblock on the triggering
edge.
Keep in mind, a regular event is not allowed with a wait
statement currently. Allowing them in a wait statement
with new behavior that treats a regular event as always
triggered is wrong. We wouldn't need this change if we
eliminated the "event bit" and instead just allowed the
trigger operator on a bit. If changing the declaration
is only one of many changes that must be made to switch
between event and self resetting bit and vice versa, then
don't "enhance" the wait.
The only difference between wait and event control is
when a persistent event has already been triggered *in
this timestep*. The reason for creating the persistent
event is to handle the problem of events that get triggered
before the event control has been activated. The proposal
really should extend the event control instead of extending
wait. $wait_any is really a wait with extensions to
allow regular events. I believe that the extensions should
have been made to event control instead.
The wait extensions should no be system tasks, but part of
the language. We already have always_ff as an extension of
always and join_none as extension of join. If we don't use
event control, we need to at least make these wait_all vs
$wait_all, etc.
>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.
Solving all the races would be fine if the solution is easy
to adopt. The current proposal is awkward enough that I would
vote in favor of a nonblocking events instead. They solve *all*
the races in the same way nonblocking assignments solve all
races, when used with a decent methodology. With some small
changes to the proposal, I would find it more desireable.
Stefen
>
>----- Original Message -----
>From: <mailto:stefen@boyd.com>Stefen Boyd
>To: <mailto:Arturo.Salz@synopsys.COM>Arturo Salz
>Cc: <mailto:sv-ec@eda.org>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 (408)739-1402 (fax)
--------------------
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 : Mon Feb 10 2003 - 10:39:40 PST