Subject: RE: Resend on meaning of wait_order FW: [sv-ec] Re: $wait_all/any/...
From: Jay Lawrence (lawrence@cadence.com)
Date: Thu Mar 13 2003 - 12:58:28 PST
No I really don't care, I just want the same answer to the same
question. I'm cursed with an email memory that recalls these things
months later (in this case only 2 months).
The stricter semantics are necessary if you don't want to allow
overlapping occurrences of the event order to occur. You'ld need to
spawn off a separate process to check this. I think the "looser"
semantics are more accurate for typical pipeline type transactions.
Jay
===================================
Jay Lawrence
Architect - Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
> -----Original Message-----
> From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> Sent: Thursday, March 13, 2003 3:56 PM
> To: Jay Lawrence; sv-ec
> Subject: Re: Resend on meaning of wait_order FW: [sv-ec] Re:
> $wait_all/any/...
>
>
> Jay,
>
> What can I say. I had it right the first time.
> @( a then ( b and not (c or d) ) then (c and not d) then d);
>
> That's what happens when I reply on weekends :)
>
> Do you believe that we need to provide both semantics?
>
> Arturo
>
> ----- Original Message -----
> From: "Jay Lawrence" <lawrence@cadence.com>
> To: "sv-ec" <sv-ec@eda.org>
> Sent: Thursday, March 13, 2003 12:40 PM
> Subject: Resend on meaning of wait_order FW: [sv-ec] Re:
> $wait_all/any/...
>
>
>
> Here is the last time we discussed $wait_order in the context of @(a
> then b then c).
>
> Jay
>
>
> ===================================
> Jay Lawrence
> Architect - Functional Verification
> Cadence Design Systems, Inc.
> (978) 262-6294
> lawrence@cadence.com
> ===================================
>
> -----Original Message-----
> From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> Sent: Sunday, January 05, 2003 6:39 PM
> To: Jay Lawrence
> Cc: sv-ec@eda.org
> Subject: Re: [sv-ec] Re: $wait_all/any/...
>
>
> Jay,
>
> You caught a bug in my expression, it should be as you wrote it:
> @( a then ( b and not (a or c or d) ) the (c and not (a or b or d))
> ...
>
> The intent is that another 'a' cannot occur for before the experssion
> ends.
>
> I don't think that bringing this issue under the 'first/last match'
> debate in
> sv-ac is warranted. The semantics of this construct are clear and
> simple.
> Unlike assertions, these expressions execute in the procedural context
> so
> users are free to break up the event sequence into multiple statements
> and execute arbitrary code in between them.
>
> Arturo
>
> ----- Original Message -----
> From: "Jay Lawrence" <lawrence@cadence.com>
> To: "Arturo Salz" <Arturo.Salz@synopsys.COM>; <mac@verisity.com>
> Cc: <sv-ec@eda.org>
> Sent: Monday, December 23, 2002 7:05 AM
> Subject: RE: [sv-ec] Re: $wait_all/any/...
>
>
>
> 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 : Thu Mar 13 2003 - 13:03:32 PST