Subject: Re: [sv-ec] Re: $wait_all/any/... (Forward of bounced email from Arturo Salz)
From: David W. Smith (david.smith@synopsys.com)
Date: Thu Dec 19 2002 - 13:34:04 PST
Stu,
The difference between $wait_all(x,y,z) and @(x && y && z) is that =
$wait_all actually works whereas the second form doesn't work. Most Verilog
compilers will = flag that expression as an error, and even if they don't,
it won't work because = the events will not trigger at the same time. The
$wait_all with non-persistent events = is semantically more like this:
fork
@ x;
@ y;
@ z;
join
The second form, $wait_any is equivalent to @(x or b or z) with the =
exception that both $wait_all and $wait_any will work with either persistent
and = non-persistent events. =20
We've also been thinking about the dual usage of the all, any keywords = and
treat this as wait all( ... ) wait any ( ... ) and possibly wait seq( ... )
= for wait_order (seq is the keyword for defining sequences in sv-ac).
Regarding $wait_order, I think you all missed one important property (it =
may be that the document could stress this better). A $wait_order requires
that the = events occur in strict order, that is if ANY event is received
out-of-order the call = fails. It is this distinction that makes wait_order
special and not at all like:
@d @e @f <statement>
The assertions committee has syntax that allows easy specification of = some
sequences like the above, but they have no syntax for specifying this strict
= ordering in a succinct way. It is a lot of code in both assertions and
regular Verilog. = That's why we proposed it. And, finally, wait_order is
guaranteed to work with both persistent and = non-persistent events by
enforcing that only the first event in the sequence can be = triggered at
the time of the call.
Arturo
----- Original Message -----=20
From: Stuart Sutherland=20
To: Kevin Cameron ; sv-ec@eda.org=20
Sent: Wednesday, December 18, 2002 3:42 PM
Subject: Re: [sv-ec] Re: $wait_all/any/...
My thoughts are inserted below...
Stu
At 03:02 PM 12/18/2002, Kevin Cameron wrote:
Link: Replace 12=20
Having posted a list of keywords that shouldn't be, I have to say =
these=20
look like they should be keywords rather than system tasks (if they=20
are actually needed).=20
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.
What's the difference between:=20
$wait_all(x,y,z)=20
and=20
@(x && y && z)=20
?=20
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=20
$wait_any(a,b,c)=20
and=20
@(a or b or c)=20
?=20
- Persistance is a property of the event not of the wait, so I don't =
see why=20
we need them.=20
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:=20
$wait_order(d,e,f)=20
becomes:=20
@(ordered(d,e,f))=20
which lets you do more complex conditions:=20
@(reset or ordered(d,e,f))=20
However, there is probably syntax for assertions that already does =
that=20
without extra keywords/functions - which we should just reuse.=20
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?
=20
I still think we should differentiate between actual events =
(Verilog) and=20
dynamic events (donation) with syntax. E.g. the example in (12.8.2) =
becomes=20
something like:=20
event a,d, // events=20
&b, &c; // event references=20
b &=3D a;=20
-> c; // null operation=20
-> a; // also triggers b=20
-> b; // also triggers a=20
c &=3D b; // c now refers to a too=20
-> a; // also triggers b and c=20
-> b; // also triggers a and c=20
-> c; // also triggers a and b=20
loop1: always @(c) begin=20
...=20
c &=3D null; // block at loop1 until reassigned=20
end=20
always @(reset) c &=3D a; // reactivate loop1=20
always @(set) c &=3D d; // reactivate loop1=20
=20
The proposed scheme defies easy analysis.=20
I don't know about defying analysis, but it sure look readable, =
intuitive, and Verilog-like to me. I like it!
Kev.=20
--=20
National Semiconductor, Tel: (408) 721 3251=20
2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA =
95052-8090=20
=20
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 - 13:33:49 PST