Subject: Re: [sv-ec] Re: $wait_all/any/...
From: Michael McNamara (mac@verisity.com)
Date: Fri Jan 24 2003 - 08:25:52 PST
Stefen Boyd writes:
> I'll throw my comments into this thread...
>
> There has been a lot of really good discussion that has
> made me think more about events and how I would like to use
> them.
>
> Kevin's contribution: Use event control syntax instead of
> $wait_xxx.
> I really like the idea of using event syntax for this
> functionality rather than these special system tasks
> largely because I find it a much more natural way to
> use these persistent events.
>
> Mac's contribution: use OR, AND, and THEN to specify equivalents
> to the $wait_xxx
> @(a AND b) seems like a great way to extend event control.
> Sure, it deals with the issue of adding new system tasks
> that aren't really supposed to be overridden by users,
> but the most compelling benefit is that it is more in
> the spirit of Verilog.
> Since THEN isn't already a keyword, perhaps we need to either
> use a token that's already reserved. I don't know of any
> reserved words that we could reuse, and I'd kinda like '->'
> if it wasn't a likely candidate for pointer deref. I
> would think we could borrow syntax from what sv-ac generates
> whenever we get their contribution to the document.
> Since the sv-ac syntax may not mean generate an error when
> the sequence is not followed (like the $wait_order), I
> see two possible paths to take:
> 1) Generate the errors from an event control using that
> same syntax, even though it is different then
> what happens with the assertion.
> 2) Why generate errors? That's what assertions are supposed
> to do for me! This is just a fancy way to do event
> control on a sequence. If you want an error for
> not following the sequence, then add an assertion
> for it.
> My preference is #2. Generating errors for failure to follow
> a sequence seems more of an assertion problem. The $wait_order
> seems to mix two different functions: event control and
> assertions
>
> Jay's contribution: ->>
> This makes a lot of sense to me. I saw the arguments related
> to the persistent event and am not completely convinced of
> it's necessity if we had a nonblocking event trigger.
>
> Stefen
>
>
>
> --------------------
> Stefen Boyd Boyd Technology, Inc.
> stefen@BoydTechInc.com (408)739-BOYD
> www.BoydTechInc.com (408)739-1402 (fax)
>
What is the problem with using '->' for event sequencing? It of
course as a unary operator how one causes events, so it is not
unnatural to use it also as a binary operator relating to events.
Using it as a binary operator for dereferencing pointers (a` la' C)
seems to be less logical that keeping it firmly associated with
events.
Another place to look for operators is the specify block space. There
we do have => and *> as parallel and full connection operators;
perhaps there is some logic to lift from these to apply to sequence
algebra?
always @ ( stefen_proposal, cliff_proposal, stu_proposal =>
mac_sends_email) begin
$display("hello");
end
This archive was generated by hypermail 2b28 : Fri Jan 24 2003 - 08:26:54 PST