Subject: Re: [sv-ec] Re: $wait_all/any/...
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Fri Dec 20 2002 - 14:02:13 PST
Please see my comments inserted after Kevin's, below...
Stu
At 10:58 AM 12/20/2002, Kevin Cameron x3251 wrote:
> > From owner-sv-ec@server.eda.org Fri Dec 20 09:54:38 2002
> > X-Sender: stuart@mail.sutherland-hdl.com
> > To: sv-ec@server.eda.org
> > From: "Stuart Sutherland" <stuart@sutherland-hdl.com>
> > Subject: Re: [sv-ec] Re: $wait_all/any/...
> >
> > 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
>
>These are my alternatives:
>
> wait_any -> @(<event>,...) As per Verilog 2001
>
> wait_all -> @(<event> and <event> and ...) Plus <event>.active for
> persistance
> rather than "event bit"
>
> join_none -> join 0
> join_any -> join 1
> join_all -> join Old behavior
>
> join <expression> Programmable join
>
>
>No new keywords and adds useful extra functionality. In what way is
>the meaning obscure or error prone?
>
>I'm still not convinced that the priority/sequence stuff is not covered
>by the AC work, but if it isn't I'd rather go for it being an event
>function so that it can be used with @, e.g.:
>
> always @(posedge reset or priority(good,bad,ugly)) ...
>
>
>Kev.
I absolutely cannot accept using numbers to modify the behavior. "join 0"
and such would create unreadable code, unless the user was kind enough to
add some comments. Any of the alternate methods that have been tossed
around are far, far better than making the code excessively
obfuscated. That's just my opinion, of course.
I agree that "wait_any" is not essential, because the functionality already
exists in Verilog. The same is true for "join_all". My feeling, however,
is that if we can make Verilog code more self documenting by adding a
keyword that is not a common word, then there is value. Verilog only has
one type of "join" and one type of "wait". There is no clarification
needed as to what the intent is. SystemVerilog is adding various types of
joins and waits. Therefore, adding keywords that explicitly show which
type of join or wait is intended helps make code more self-documenting. It
also helps users think about what their intent is. This is not a new
concept to Verilog. The language already has several synonyms;
module/macromodule, wire/tri, wand/triand and wor/trior are some that
immediately come to my mind. Adding synonyms such as join/join_all and
wait/wait_any simply give coders a way to create better self-documenting code.
But, I must reiterate that I am only OK with adding keywords that do not
give new functionality if the keyword is not a common word, and does help
describe the intent of the code.
The use of "priority" as a function within the sensitivity list has
issues. First, "priority" is already a reserved keyword, and cannot--or
should not--be doubly used as a function name. Second, it is my
understanding that there is an issue in existing Verilog implementations on
functions calls within a sensitivity list. Some simulators are sensitive
to the function arguments, and some are sensitive to the function
return. I believe (without double checking) that most synthesis tools
simply make functions within sensitivity lists illegal.
I regards to context sensitive keywords...I'm not opposed to the idea. Off
hand, I cannot think of any precedence in the Verilog language for this. I
know there has been some threads on the topic before, but did not follow
them closely. My impression was that there was a lot of concern regarding
introducing context sensitive keywords to Verilog. It would be important
to be consistent on the usage. I would not like to see "wait any" and
"join=any". Nor do I like the equal sign in that context.
I have another concern that I have not seen addressed at all. Maybe it is
in the original proposal, and I overlooked it. What ever is added to
"wait" expressions or to "@" sensitivity lists to support the enhanced
event type, must also very explicitly define how all other Verilog data
types and expressions behave in that context. And what about arrays? Now
that I have events with a value, can I have a packed array of events? Can
packed or unpacked arrays of events be used with these new wait
statements? Everything needs to be defined.
I will drop out of this thread, now, and try to get some real work
done. I've said my $0.02's worth.
Stu
> >
> > 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
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
> >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 - 14:19:23 PST