Subject: Re: [sv-ec] Re: $wait_all/any/...
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Fri Dec 20 2002 - 17:16:42 PST
Mac,
Thanks for providing such a lucid and clear explanation of event semantics.
I have no problems with your "creative" syntax, it's clear, concise, and, I
believe, in the spirit of Verilog. I do think that you misunderstood the exact
semantics of wait-order. When I wrote earlier that wait-order means strictly
in that order, I meant that all the events must occur in precisely that order,
and no event can occur out of order. If one were to express something like
wait_order(a, b, c, d) using the syntax you propose, we'd have to write:
@( a then ( b and not (c or d) ) then (c and not d) then d);
Of course, I've just cooked up a whole lot of non-existent syntax but I hope
this helps to explain the semantics, and the reason why this construct is
so valuable. And, by the way, the assertions do
provide a very simple syntax for describing a sequence of events:
seq = a ## b ## c ## d; (or something like that)
But, the difference is that all those expressions are clocked, whereas the
events can be asynchronous.
Arturo
----- Original Message -----
From: "Michael McNamara" <mac@verisity.com>
To: "Stuart Sutherland" <stuart@sutherland-hdl.com>
Cc: <sv-ec@eda.org>
Sent: Friday, December 20, 2002 3:17 PM
Subject: Re: [sv-ec] Re: $wait_all/any/...
While we are being creative here, why not:
always @(a or b) ; // equivalnet to wait any
always @(a and b); // equivalent to wait all
always @(a then b); // equivalent to wait priority
None of these need a new keyword
The new ones are currently illegal verilog, so no current designs
would be broken by this addition.
[By the way, the previous two questions are a criteria that must be
carefully considered before making any change to a live language, in
my opinion].
Of course, number two [ @ (a and b) ] can already be done for entities
things other than events by:
always @(a && b);
As for events: this may be a suprise to some; but events do not
happen silmultaneously! Events are triggered one by one, and
things that are blocking on an event are released; and then
other events may be triggered. Specifically:
always @(a) -> e1;
always @(a) -> e2;
always @( e1 and e2 ) ; // This will never fire, even if it was
// legal syntax, as while e1 and e2 will
// both spike true in the cycles that 'a'
// changes, the spikes will NOT overlap.
Of course, number three [@ (a then b ) ] can already be done today by:
always begin
@(a);
@(b);
end
So again I return to what is the value of adding these constructs?
-> They do not give any more power to Verilog's capability;
-> They do not as Vassilous hopes replace four lines of 1364 Verilog
with 1 line of System Verilog;
-> and instead they add a redundant, slightly different way of doing
something that is already possible in Verilog 1364-1995.
Stuart Sutherland writes:
> Vassilios makes a good point (in a separate e-mail) that we need to be
> careful about sacrificing language clarity just to avoid adding
> keywords. Using operators in an event sensitivity list instead of using
> keywords would make the constructs more obscure, and therefore more error
> prone.
>
> I propose that we narrow this discussion down to two options:
>
> Option One - multiple use of "any", "all" and "priority" keywords:
> wait any
> wait all
> wait priority (instead of "wait order")
> join none
> join any
> join all
> join priority
>
> Note that "priority" is already reserved in SystemVerilog,
> and with a similar meaning of prioritized order. Using
> "priority" avoids having to reserve "order" as a keyword.
>
> Option Two - add unique, non-common keywords:
> wait_any
> wait_all
> wait_priority
> join_none
> join_any
> join_all
> join_priority
>
> My personal preference is Option Two. Either option clearly documents
> intent and is straight forward to use. The multiple use of "any", "all",
> gives some justification to making them keywords, but I am still concerned
> about reserving keywords that are common words. That will very likely
> cause compatibility issues with existing Verilog models. Option Two
> reserves more keywords than Option One, but the keywords are not likely to
> have any impact on existing models.
>
> We should keep in mind that user's cannot not always easily change an
> existing model to make it compatible with SystemVerilog. The model may be
> an IP model or part of library which should only be changed by the model
> provider. The model may be source code protected, making it impossible to
> change without a key. The model may be locked from changes by version
> control software, etc. SystemVerilog 3.0 already adds some keywords that
> make this a serious issue. But that is not a good reason to exacerbate the
> problem. Any time we can add the functionality and simplicity we desire
> reserving non-common keywords, that should be the preferred
> approach. There are times when a more common word is the best choice (e.g.
> "class") because of its clarity for those coming from a C/C++
> background. In the case of modifiers for "wait" and "join", however, we
> can achieve clarity with non-common words.
>
> I would also like to point out that "join priority" or "wait priority" are
> not orthogonal with "priority if" and "priority case". Should the modifier
> be before or after the object? Maybe it's not a big deal, but it is
different.
>
> Stu
>
>
> At 11:54 PM 12/19/2002, Arturo Salz wrote:
> >Mac,
> >
> >You make an excellent case for keeping these constructs in the language and
> >not via system tasks. Also, the wait_order is clearly the most useful of
> >the 3
> >constructs. The other 2 wait-all/wait-any are there for orthogonality and
> >completeness. If we can support all of these using existing operators that
> >would be good.
> >
> > Arturo
> >
> >----- Original Message -----
> >From: "Michael McNamara" <mac@verisity.com>
> >To: "Arturo Salz" <Arturo.Salz@synopsys.COM>
> >Cc: "Kevin Cameron" <Kevin.Cameron@nsc.com>; <sv-ec@eda.org>
> >Sent: Thursday, December 19, 2002 3:43 PM
> >Subject: Re: [sv-ec] Re: $wait_all/any/... (Forward of bounced emailfrom
> >Arturo Salz)
> >
> >
> >
> >Introducing a system task ($wait_all) for a scheduling task, which
> >replicates what can already be done in every verilog 1364-1995
> >compliant simulator:
> >
> >always begin fork @a; @b; @c; join
> >
> >end
> >
> >seems to be
> >
> >1) unnecessarily introducing an additional way to do something that
> > can already be done with even 1995 compliant simulators.
> >
> >2) slower (to implement this one needs to cross the pli boundry, set
> > call backs on all of the operands to the task, and then somehow
> > block further execution of the statement guarded by the $wait_all,
> > yet allow execution of the rest of the simulation so that these
> > events might occur)
> >
> >3) require semantic changes (how does a system task request the
> > simulator to block execution of the guarded statement (other than by
> > refusing to return), while also retruning control to the simulator
> > so that the guard events may occur?
> >
> >4) can be overridden (users can define their own user task that
> > overrides a system task, and perhaps already have a task called
> > $wait_all).
> >
> >Arturo Salz writes:
> > > Kev,
> > >
> > > I appreciate your point, but I miss where you are going with this.
> > > The persistency property needs to be part of the declaration since
> > > it's not possible to determine this from the usage (since events can
> > > appear anywhere in a dynamic context). Otherwise, we run the
> > > risk of forcing all events to implement persistency, something that
> > > can have adverse performance consequences.
> > >
> > > Arturo
> > >
> > > ----- Original Message -----
> > > From: "Kevin Cameron" <Kevin.Cameron@nsc.com>
> > > Cc: <sv-ec@eda.org>
> > > Sent: Thursday, December 19, 2002 2:45 PM
> > > Subject: Re: [sv-ec] Re: $wait_all/any/... (Forward of bounced
> > emailfrom Arturo Salz)
> > >
> > >
> > >
> > > "Arturo" wrote:
> > >
> > > > 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
> > >
> > > I understand why @(x && y) doesn't work for non-persistent events, but
> > I don't
> > > see why it can't work with persistant events.
> > >
> > > Since we are moving to using <object>.<method> syntax for other things
> > we could
> > > add methods to events so that you wouldn't need to differentiate e.g.:
> > >
> > > event x,y;
> > > always @(x.active && y.active) ...
> > >
> > > "active" would be true for any event for the simulation cycle in which
> > the event occurs.
> > > No need to add "event bit".
> > >
> > > There are lots of alternatives to using system tasks and keywords.
> > >
> > > Kev.
> > >
> > > > 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
> > > >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =
> > >
> > > --
> > > 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 : Fri Dec 20 2002 - 17:10:09 PST