Subject: Re: [sv-ec] Section 12.6.4 - wait
From: Stefen Boyd (stefen@boyd.com)
Date: Fri Feb 07 2003 - 10:47:00 PST
Kevin,
I have one significant problem with .active - It's way too
verbose. It also means lots of modifications to a coded model
to avoid races. I don't necessarily have a problem with 'event bit'
so long as we do one of:
- clarify that it's a special bit (and call it something
that reflects what it really is - like "one-shot bit"
since it really isn't an event)
- make it a special event and make it work with *event*
control
Otherwise, we should consider using a nonblocking event, or
even your implicit signal (which I find excessively verbose).
Of all the choices, adding "bit" to the event declaration and
having all the other event related code "just work" would be
the ideal. Second choice is non-blocking event.
Stefen
At 10:13 AM 2/7/2003 -0800, Kevin Cameron x3251 wrote:
>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.
--------------------
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:47:16 PST