Subject: Re: [sv-ec] Re: $wait_all/any/...
From: Faisal Haque (fhaque@cisco.com)
Date: Fri Dec 20 2002 - 19:59:35 PST
Michael,
To answer your question about assertions yes DWG is is developing the
language LRM for System Verilog assertions.
-Faisal
----- 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 : Fri Dec 20 2002 - 20:00:31 PST