Subject: RE: [sv-ec] Re: $wait_all/any/...
From: Jay Lawrence (lawrence@cadence.com)
Date: Mon Dec 23 2002 - 07:05:27 PST
I do like the 'or' 'and' 'then' syntax and don't see why it couldn't be
defined to mean the expression
> @( a then ( b and not (c or d) ) then (c and not d) then d);
That Arturo suggests is the true meaning.
By way of clarification Arturo. Is there a reason you did not say:
@( a then ( b and not (a or c or d) ) the (c and not (a or b or
d)) ...
This adds the semantic that another 'a' can not occur before the
sequence is complete.
This whole debate is almost a complete replay of the 'first match',
'last match', 'all match' debate in vc-ac. The next logical extension is
allowing these statements to recognize overlapping sequences of these
things...
I believe we should clarify all the desired wait semantics that are
required and then when the DWG work is complete we can incorporate the
syntax from that world.
Jay
> -----Original Message-----
> From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> Sent: Friday, December 20, 2002 8:17 PM
> To: mac@verisity.com
> Cc: sv-ec@eda.org
> Subject: Re: [sv-ec] Re: $wait_all/any/...
>
>
> 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 : Mon Dec 23 2002 - 07:09:55 PST