Subject: Re: [sv-ec] Section 12.6.4 - wait
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Thu Feb 06 2003 - 17:52:21 PST
Stefen,
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.
Arturo
----- Original Message -----
From: "Stefen Boyd" <stefen@boyd.com>
To: <sv-ec@eda.org>
Sent: Thursday, February 06, 2003 5:24 PM
Subject: [sv-ec] Section 12.6.4 - wait
Assuming we haven't all been convinced to abandon persistent
events by Jay's non-blocking event (->> operator), it looks
like we need to clarify the purpose of wait on a persistent
event. Since it's persistent for the entire cycle, it seems
that the wait isn't needed, we just need to clarify that
event control ('@' operator) such as @(p_event) would unblock
when p_event has already been triggered, but is persistent.
Am I missing something? It's not clear, but it would appear
that a user would have to recode if they decided to switch
from regular events to persistent.
Case 1: I change a persistent event to a regular event
- My wait statements on that event now don't do anything
(right?)
Case 2: I change a regular event to a persistent event
- Presumably trying to deal with a race between activation
of my event control and my event trigger.
- Still have race!!! (right?) Since @ still subject to
race that caused me to change to using persistent event.
- Have to recode all event control with wait statements?
Seems we need to eliminate wait and change the way event control
deals with persistent events.
Stefen
--------------------
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 : Thu Feb 06 2003 - 17:53:46 PST