Subject: Re: [sv-ec] Re: $wait_all/any/... (Forward of bounced emailfrom Arturo Salz)
From: Michael McNamara (mac@verisity.com)
Date: Thu Dec 19 2002 - 15:43:56 PST
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
>
>
>
>
This archive was generated by hypermail 2b28 : Thu Dec 19 2002 - 15:44:25 PST