RE: [sv-ac] 928 Proposal Updated

Hi Adam,

I think that the requirement to keep all arguments typed if at least one
of them is typed is too strong. Consider the following example:

property p(bit en, a, b, c, int n);
	en |=> ({a, b} == c) [*n];
endproperty

You cannot make a and b typed without loss of generality - you will have
to declare a separate property for each length combination.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda-stds.org
[mailto:owner-sv-ac@server.eda-stds.org] On Behalf Of Adam Krolnik
Sent: Tuesday, June 27, 2006 10:17 PM
To: Lisa Piper
Cc: Bassam Tabbara; john.havlicek@freescale.com;
Eduard.Cerny@synopsys.com; Korchemny, Dmitry; Brad.Pierce@synopsys.com;
sv-ac@server.eda-stds.org
Subject: Re: [sv-ac] 928 Proposal Updated



Hello Lisa;

You did not include events in your list of necessary types - for passing
in clocks, 
or resets, or other.

If one can specify a type for the argument, is it necessary to allow for
a void type?
If the new types are going to be added, I would like to see the
supported two ways to
specify the interface for the property or sequence:

1. All untyped
2. All typed

If you've gone to the trouble of giving some arguments types (for the
purposes of
helping ensure they are using them correctly) then you will give all the
arguments
a type.

Alternatively, one may not care about the type and mostly use arguments
for
signals, numbers, etc.

Lastly, is 'const' a type modifier? Is there an implicit type associated
with it?
I would expect that users would use 'int' or 'logic' instead of reaching
for const
initially. What about '$' for infinite value - it would have to be
accepted under
'const'.

    Thanks.

-- 
     Soli Deo Gloria
     Adam Krolnik
     ZSP Verification Mgr.
     LSI Logic Corp.
     Plano TX. 75074
     Co-author "Assertion-Based Design"