Subject: Re: [sv-ec] Section 12.6.4 - wait
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Feb 07 2003 - 10:13:12 PST
> From: "Stefen Boyd" <stefen@boyd.com>
>
> 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
The implicit signal version is:
event foo;
initial #100 ->foo;
...
always @(foo.active and bar.active) // true if foo and bar fire
// in same timestep
- "foo" is only true during the processing of its sensitive processes
(same as before) "foo.active" is true from then until the end of the
timestep. Essentially, the "bit" in "event bit" becomes the ".active".
No new declarations are needed, and you don't need "wait" and I
think the code is more readable.
Since ".active" can be used with events or nets you can also use it
in assertions, e.g.:
always @(data or clock)
assert (!(data.active and clock.active));
// data and clock should not change in same timestep
Kev.
> 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 - 10:13:55 PST