Subject: Re: [sv-ec] Re: $wait_all/any/... (Forward of bounced emailfrom Arturo Salz)
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Dec 19 2002 - 15:11:09 PST
> From Arturo.Salz@synopsys.com Thu Dec 19 14:50:26 2002
>
> 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
If the events were static rather than dynamic it would be easy to tell
which need to keep the persitance info. I doubt that it's that much
overhead anyway.
Even if you do use $wait_*(<event>...), it's hard to tell from the
statement itself if the events are of persistent type. Using ".active"
would make it clear what the usage is.
You could add "on" as a method too for use with $trigger:
event x;
always @(clock && x.on) ...
I think I'd prefer to keep events typeless and not use "event bit" at
all.
Kev.
> ----- 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
>
>
>
>
>
>
This archive was generated by hypermail 2b28 : Thu Dec 19 2002 - 15:11:57 PST