Re: [sv-ec] Re: $wait_all/any/...


Subject: Re: [sv-ec] Re: $wait_all/any/...
From: Stefen Boyd (stefen@boyd.com)
Date: Thu Jan 23 2003 - 17:52:15 PST


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)



This archive was generated by hypermail 2b28 : Thu Jan 23 2003 - 17:52:16 PST