Subject: Re: [sv-ec] Re: $wait_all/any/...
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Dec 20 2002 - 15:04:20 PST
> From stuart@sutherland-hdl.com Fri Dec 20 14:12:13 2002
>
> Please see my comments inserted after Kevin's, below...
And mine...
> 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 don't see how "join [<number of processes>]" is less meaningful or harder
to read, and as I said before it adds the extra functionality of being
able to continue with an arbitrary number of processes completed.
- It's a lot more obvious behavior than the "event merging" stuff.
> 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.
I don't think those old keywords are synonyms. Adding unnecessary synonyms
doesn't help make code more readable.
> 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.
Use a different keyword. The point was that what the order/seq functionality
is actually doing is processing events to create new events, so you might
as well create a nestable function as a standalone statement - it's more
flexible syntax/semantics.
> 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.
That's partly why I objected to "event bit", makes it look something like
a wire when it isn't.
> 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
This isn't real work ? :-)
Kev.
>
> > >
> > > 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 - 15:05:43 PST