Subject: Re: [sv-ac] FW: ASWG Final Status
From: Dave Rich (David.Rich@synopsys.com)
Date: Mon Mar 24 2003 - 15:16:55 PST
I would like to point out that Jay took the minutes at our last meeting
and was supposed to send out the BNF to the group internally for review
to make sure it accurately represented the decisions of our committee.
Jay has published the preliminary BNF and people have mistaken this as
the final version.
I will be sending out the final BNF results shortly after incorporating
corrections from committee members and a preliminary pass through yacc.
Dave
Jay Lawrence wrote:
>Let me take a crack at what the ASWG was thinking on these.
>
>Jay
>
>
>
>>-----Original Message-----
>>From: Adam Krolnik [mailto:krolnik@lsil.com]
>>Sent: Monday, March 24, 2003 1:52 PM
>>To: Faisal Haque
>>Cc: sv-ac@eda.org
>>Subject: Re: [sv-ac] FW: ASWG Final Status
>>
>>
>>
>>
>>Good morning all;
>>
>>Reading the document and the BNF I would like clarification
>>on what is meant.
>>
>>
>>2. Statements.
>>
>>The production module_assertion_item should be added to the
>>module_item production.
>>
>>Is the excluding the addition of assertions/properties within
>>an interface?
>>
>>
>
>
>They should be allowed in interfaces as well as far as I'm concerned.
>This will probably have to be run through the sv-ec because currently
>interfaces are explicitly only allowed to have initial and always
>blocks. I would suggest the sv-ac opens an action item with the sv-ec
>to be reviewed this month.
>
>
>
>>The statement, "Note the difference between an immediate and
>>concurrent assertion is
>>that an immediate assertion takes an expression as the
>>argument, the concurrent
>>assertion takes a property instance."
>>
>>Changing the abilities of the assert statement to only accept
>>a named property instance
>>has these effects:
>>
>>
>
>I agree with this personally, but some members of the group felt that
>this simplified everything (eliminated the need for 'check' and made
>implicit sampling less of an issue).
>
>
>
>
>>1. Sequences are no longer a first class construct. They must
>>be explicitly defined
>> separate from their context. This would be equivalent to
>>disallowing equations in
>> continuous assignment or procedural assignments and
>>requiring one to write a function
>> for each equation. Previously one could write (and many,
>>myself included expected to
>> be able to write)
>>
>> assert (a |=> b ##1 c ##1 d) else $error("Protocol for
>>myprt not followed Jim.");
>>
>> This has many benefits that movement of the sequence to a
>>separate location in the
>> code would remove. (Note the move may be hundreds of lines away!)
>>
>> 1. Assertions serve as executable documentation of the code.
>> 2. Assertions serve as reminders of how the code is
>>expected to work.
>> 3. Assertions serve as a high level model, useful for
>>nonwriters debugging
>> or reviewing the code.
>>
>> The usefulness of using an anonymous (unnamed)
>>property/sequence in an assert or
>> cover directive should be reconsidered. This is much more
>>than a syntax change.
>>
>>
>>
>
>To the extent that the sv-ac feels they can revisit this they should.
>There are 3 groups working on this and the relationship/ownership is
>very unclear to me. If the sv-ac undoes this and allows
>(sequence_phrase) in an assertion (it's easy in the grammar) then they
>also have to put back the 'check' keyword.
>
>
>
>
>>2. All properties are now required to have a name. We had
>>discussions and voted on
>> optional naming.
>>
>>
>>
>
>What would a property with no name be good for?
>
>
>
>>-----------------------
>>
>>
>>
>>4. Sequences
>>
>>Why does a sequence require two parameter lists, one with %()
>>and one with()?
>>It would seem possible to do with only one parameter list.
>>
>>
>>
>>
>
>The %() parameter list is for variables, the () list is for formals of
>objects sampled in the assertions. These are very different objects.
>You can not put a regular Verilog 'reg' in the %() list, and you can
>not put a variable declared in a property in the () list.
>
>The idea of 2 lists was borrowed from modules where you have a
>parameter list #() and a port list (). In fact, I personally believe
>that eventually sequences will also have parameters for globally static
>values, so you'll say crazy things like:
>
> S #(2) %(tag) (rdy, gnt, addr);
>
>We did discuss the alternative of having one list with new keywords
>
> sequence (var input tag, rdy, gnt, addr);
>
>But Verilog allows partial lists like this for modules and tasks where
>items in a formal list inherit capabilities from the previous items.
>For instance
>
> module(input i1, i2, output o1, o2)
>
>The port i2 above is an input because it has no mode and the i1 element
>is specified as an input so i2 inherits it; likewise o2 is an output.
>So if we went with this syntax it would be incompatible with other
>formal list specifications.
>
>
>
>>5. Templates
>>
>>There is no production generate_item in SystemVerilog. What
>>are the expected abilities?
>>Anything but port declarations?
>>
>>
>>
>
>We are still discussing this on another thread but it is quickly
>evolving that these are just fancy multiline macros with no implicit
>checking. They can have any text inside them and can be used anywhere a
>macro can be used.
>
>
>
>
>>Outstanding issue:
>>
>> Nothing was said about 'bind' functionality. Does it
>>stand in its limited form?
>>
>>
>>
>
>We never discussed it. Oooops.
>
>
>
>> Thanks.
>>
>> Adam Krolnik
>> Verification Mgr.
>> LSI Logic Corp.
>> Plano TX. 75074
>>
>>
>>
>>
>>
>
>
>
>
-- -- Dave Rich Principal Engineer, CAE, VTG Tel: 650-584-4026 Cell: 510-589-2625 DaveR@Synopsys.com
This archive was generated by hypermail 2b28 : Mon Mar 24 2003 - 15:23:55 PST