Subject: RE: [sv-ac] FW: ASWG Final Status
From: Jay Lawrence (lawrence@cadence.com)
Date: Mon Mar 24 2003 - 13:48:00 PST
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
>
>
>
This archive was generated by hypermail 2b28 : Mon Mar 24 2003 - 13:49:04 PST