Subject: Re: [sv-ec] Re: $wait_all/any/...
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Dec 19 2002 - 10:16:21 PST
> From stuart@sutherland-hdl.com Thu Dec 19 08:25:45 2002
>
> My thoughts are inserted below...
>
> Stu
>
> At 03:02 PM 12/18/2002, Kevin Cameron wrote:
> >Link: <http://www.eda.org/sv-ec/EventsDetails.html>Replace 12
> >
> >Having posted a list of keywords that shouldn't be, I have to say these
> >look like they should be keywords rather than system tasks (if they
> >are actually needed).
>
> I agree with the use of keywords here, instead of system tasks that can be
> redefined by the PLI. If we are stuck with the "any" and "all" keywords
> from the "join any" and "join all", then no new additional keywords are
> needed. One could do "wait any" and "wait all". I do not like reserving
> "any" and "all" as keywords, but a dual usage might sway me--maybe.
I'm voting for the default being "any" (so no keyword required), and otherwise
supplying the number (any = 1), e.g.:
fork ... join 1; // same as join any
fork ... join 0; // same as join none
- it's less typing, and you can wait for a pair of processes to complete
a task:
fork ... join 2;
> >What's the difference between:
> >
> > $wait_all(x,y,z)
> >
> >and
> >
> > @(x && y && z)
> >
> >?
>
>
> At least one difference in Verilog is the ambiguity of whether to trigger
> on a change on the operand or a change on the result. SystemVerilog 3.0
> adds the "changed" keyword, which would resolve that ambiguity.
>
> I'm not clear if the $wait_and means at least two of the event types must
> be true before the third one is triggered (which would require the events
> have persistence) or that all three events must trigger, but it can happen
> in any order (which would require the @ emulate a state machine). If it is
> the former, then @(changed (x&&y&&z)) would do what I need without
> $wait_all or a new keyword. If it is the latter, then $wait_all or a new
> keyword is necessary. That's how I see it, at least.
>
>
> >Or between
> >
> > $wait_any(a,b,c)
> >
> >and
> >
> > @(a or b or c)
> >
> >?
> >
> >- Persistance is a property of the event not of the wait, so I don't see why
> >we need them.
>
> I agree. Verilog does this already, so neither $wait_any or a new keyword
> is needed.
>
>
> >$wait_order could be broken down into an order call:
> >
> > $wait_order(d,e,f)
> >
> >becomes:
> >
> > @(ordered(d,e,f))
> >
> >which lets you do more complex conditions:
> >
> > @(reset or ordered(d,e,f))
> >
> >However, there is probably syntax for assertions that already does that
> >without extra keywords/functions - which we should just reuse.
>
> Ordered events are already possible in plain old Verilog:
>
> @d @e @f <statement>
>
> But, I like the "ordered" modifier. It is intuitive and fits well with
> @(changed ...). It makes the complex condition above easy to code.
>
> Hmmm, does the "iff" keyword help with any of this?
>
> >
> >
> >I still think we should differentiate between actual events (Verilog) and
> >dynamic events (donation) with syntax. E.g. the example in (12.8.2) becomes
> >something like:
> >
> >event a,d, // events
> > &b, &c; // event references
> >
> > b &= a;
> > -> c; // null operation
> > -> a; // also triggers b
> > -> b; // also triggers a
> > c &= b; // c now refers to a too
> > -> a; // also triggers b and c
> > -> b; // also triggers a and c
> > -> c; // also triggers a and b
> >
> > loop1: always @(c) begin
> > ...
> > c &= null; // block at loop1 until reassigned
> > end
> >
> > always @(reset) c &= a; // reactivate loop1
> > always @(set) c &= d; // reactivate loop1
> >
> >
> >The proposed scheme defies easy analysis.
>
> I don't know about defying analysis, but it sure look readable, intuitive,
> and Verilog-like to me. I like it!
[This refers to "merging events" etc. in the 3.1 changes document]
It's really not as simple/intuitive as it looks. It may be OK for testbenches
but the syntax and semantics make it very difficult to work out which objects
are actually persistent things that can be synthesized into wires. My
alternative above (assuming module scope) has two permanent event objects (a
and d) and seperate event references, I think it's easy to see that that
would probably synthesize into a couple of wires and a couple of muxes. In
the 3.1 draft all declared events are effectively references to dynamically
created objects so you can't infer how many actual event structures are
needed from static analysis.
I'm not objecting to the functionality, it's just that committing to the 3.1
draft syntax precludes easy differentiation static and dynamic objects, which
impacts optimization and synthesis. It will be difficult to fix it later.
Kev.
> >Kev.
> >
> >--
> >National Semiconductor, Tel: (408) 721 3251
> >2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland Sutherland HDL Inc.
> stuart@sutherland-hdl.com 22805 SW 92nd Place
> phone: 503-692-0898 Tualatin, OR 97062
> www.sutherland-hdl.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Thu Dec 19 2002 - 10:17:18 PST