Subject: Re: [sv-ec] Section 12.6.4 - wait
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Feb 06 2003 - 18:01:11 PST
> From: "Stefen Boyd" <stefen@boyd.com>
>
> 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)
There is still the alternative of adding an implicit signal that
supports "persistance" for events (and nets). That doesn't
change the declaration of events or the syntax of assignments.
See - http://www.eda.org/sv-ec/hm/0368.html
I think it's a more user friendly approach since it's more obvious
to someone reading someone else's code what is happening.
Kev.
This archive was generated by hypermail 2b28 : Thu Feb 06 2003 - 18:01:58 PST