Subject: RE: [sv-ec] Re: $wait_all/any/...
From: Erich Marschner (erichm@cadence.com)
Date: Tue Dec 31 2002 - 08:07:41 PST
Arturo,
Your comment below:
| The Accellera PSL effort will provide SystemVerilog with assertions
| and sequences. However, all the property languages on which it is
| based (Sugar, ForSpec, OVA) are strictly synchronous languages,
is incorrect in two ways.
First, it suggests that Accellera PSL is somehow based on ForSpec and OVA. You know as well as I do that this is at least misleading if not simply false. Accellera PSL is based on Sugar, not on ForSpec (which was rejected by the FVTC) or on OVA (which is essentially a repackaging of ForSpec). If you meant to say that Sugar, ForSpec, and OVA are all based on LTL, that would be correct, but that doesn't imply that Accellera PSL is based on ForSpec or OVA.
Second, Accellera PSL is not a strictly synchronous language, as Bernard pointed out. Unlike ForSpec and OVA, Accellera PSL supports asynchronous assertions (clocked or otherwise) in a completely transparent fashion.
Regards,
Erich Marschner
Co-Chair, Accellera FVTC
-------------------------------------------
Erich Marschner, Cadence Design Systems
Senior Architect, Advanced Verification
Phone: +1 410 750 6995 Email: erichm@cadence.com
Vmail: +1 410 872 4369 Email: erichm@comcast.net
| -----Original Message-----
| From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
| Sent: Friday, December 20, 2002 9:46 PM
| To: mac@verisity.com
| Cc: sv-ec@eda.org
| Subject: Re: [sv-ec] Re: $wait_all/any/...
|
|
| The Accellera PSL effort will provide SystemVerilog with assertions
| and sequences. However, all the property languages on which it is
| based (Sugar, ForSpec, OVA) are strictly synchronous languages,
| that is, each temporal statement in a sequence is sampled and
| evaluated using a particular clock (an event or an edge). This means
| that the entire sequence is synchronous to a clock. Verilog's event
| mechanism has no such limitation and neither would the wait_*
| constructs proposed. That is one distinction between the two
| approaches. Also, none of these assertion languages have a succinct
| syntax for specifying the strict ordering semantics of wait_order and
| they would have to be spelled out in a manner similar to my last
| message.
|
| I hope this helps clear things up.
|
| Arturo
|
| Happy Holidays to all.
|
| ----- Original Message -----
| From: "Michael McNamara" <mac@verisity.com>
| To: "Arturo Salz" <Arturo.Salz@synopsys.COM>
| Cc: <mac@verisity.com>; <sv-ec@eda.org>
| Sent: Friday, December 20, 2002 5:56 PM
| Subject: Re: [sv-ec] Re: $wait_all/any/...
|
|
|
| I must say it is much more enjoyable to engage in dialog with you,
| than with certain other folks...
|
| Thank you for you further explainiation of the distinction between
| wait_order and a simple @(a); @(b).
|
| With the further semantics of wait_order explained, I see it as being
| mush more similar to the property specification languages (sugar, e,
| Forspec, CBV) that have rich semantics for specifying sequences that
| behave as you describe; as well as allowing branches and recognizing
| bad sequences and killing a main sequence.
|
| Help me understand the game plan. Are we not going to get syntax for
| assertions and sequences from the Accellera PSL effort by virtue of
| the DWG?
|
| I apologize for perhaps not paying attention to some email where this
| was all coherantly explained.
|
| -- an aside --
|
| I want to wish Happy Holidays to all; I am, and I assume many of you
| are off for some end of year vacation. Please everyone, be careful
| out there. The snow will still be there when you arrive; drive
| conservatively. Arrive alive!
|
| -mac
|
| Arturo Salz writes:
| > 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 : Tue Dec 31 2002 - 08:08:24 PST