RE: [sv-ac] RE: minor comments on 1549

Hi John,

I believe the use of parameters is most consistent. Using parameters
would provide properties with the same abstraction mechanism as classes
- SV parameterized classes are equivalent to C++ template classes.
Because properties are instantiated, I believe parameters will be less
confusing. I would envision something like:

   sequence SEQ #( shortint delay1 = 1, int delay2 = 2, int min = 0, int
max = 1 );
       x  ##delay1   y[*min:max]   ##delay2  z;
   endsequence
 
   cover property SEQ#( 2, 2, 3 $ );
OR
   cover property SEQ#( `my_delay, `my_delay - 1, ... );

This makes it very clear that the parameters are all elaboration
constants that affect the "shape" and "size" of the property, and not a
procedural variable.

BTW, this mechanism would allow users to create generic properties whose
types are parameters, as for example:

   property foo #(type T = logic, int delay = 5 );
       T localv;
       (x, localv = in_v) |-> ## delay (out_v == localv);
   endproperty

   typedef struct packed { ... } xyz;

   assert foo#( xyz );

I believe this is closer to the intent.

	Arturo

-----Original Message-----
From: John Havlicek [mailto:john.havlicek@freescale.com] 
Sent: Tuesday, September 05, 2006 5:59 AM
To: Arturo.Salz@synopsys.COM
Cc: piper@cadence.com; john.havlicek@freescale.com; sv-ac@eda-stds.org
Subject: Re: [sv-ac] RE: minor comments on 1549

Hi Arturo:

I agree that the suggested use of const to indicate a compile-time
constant is not consistent with its use elsewhere.

However, I would like to see the argument types in sequence and
property declarations do a better job of telling the instantiator of
the sequence or property what actual argument expressions are legal.

I see several alternatives:

1. Use const as suggested and accept the inconsistency in exchange
   for avoiding a new keyword.

2. Find a different keyword than const.

3. Introduce parameters to the sequence and property constructs.

Which of these looks best to you?

J.H.

> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Thu, 31 Aug 2006 13:05:09 -0400
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] RE: minor comments on 1549
> Thread-Index: AcbLdwtjqYEYUGn2SqKZT7bT6rwKsQA9K3kAACrmukAAARefUA==
> From: "Lisa Piper" <piper@cadence.com>
> X-Received: By mx-sanjose2.Cadence.COM as k7VH5DZ5008925 at Thu Aug 31
10:05:14 2006
> X-OriginalArrivalTime: 31 Aug 2006 17:05:20.0905 (UTC)
FILETIME=[A431DF90:01C6CD1F]
> 
> This is a multi-part message in MIME format.
> 
> ------_=_NextPart_001_01C6CD1F.A54FD2AF
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> =20
> 
> =20
> 
> ________________________________
> 
> From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]=20
> Sent: Thursday, August 31, 2006 12:32 PM
> To: Lisa Piper; john.havlicek@freescale.com; sv-ac@eda-stds.org
> Subject: RE: [sv-ac] RE: minor comments on 1549
> 
> =20
> 
> This proposal seems inconsistent with the general meaning of const in
> the rest of the language: A const declaration is computed after
> elaboration and what I believe you want here is to have the semantics
of
> a parameter.=20
> 
> Wouldn't it be simpler to trigger an error when the delay or
repetition
> argument was not an elaboration time constant - the desired semantics
-
> rather than require users to specify this additional check using a
const
> modifier?=20
> 
> [Lisa Piper >>>] the intent is that you can provide the interface to a
> user and they will know that this needs to be a constant.  This would
> help, for example,  the user of a property library that does not know
> SVA real well.
> 
> I don't understand what it means when you say "this is strongly
> recommended for all parameters". Since a property is instantiated at
> elaboration time, how could the parameters be anything other than
> constants? Surely they cannot be depend on procedural code.
> 
> [Lisa Piper >>>] The tool would give an error regardless so it is not
> required, just recommended to help the user
> 
> =20
> 
> Also, there is a slight mistake in the example: It should be (the =3D
=
> and
> ; are incorrect): `define my_delay 2
> 
> [Lisa Piper >>>] oops! Thanks!
> 
> =20
> 
>             Arturo
> 
> =20
> 
> ________________________________
> 
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Lisa
> Piper
> Sent: Thursday, August 31, 2006 8:50 AM
> To: john.havlicek@freescale.com; sv-ac@eda-stds.org
> Subject: [sv-ac] RE: minor comments on 1549
> 
> =20
> 
> I have changed the new types proposal as suggested by John with the
> exception of the comment about passing delay and repetition values as
> compile time constants.  Would people object to my adding the
following
> to this proposal (versus making it a separate standalone proposal).
> There may be other qualifiers that are desired too but they will
likely
> need more discussion.  I think this an obvious one though that is very
> important.
> 
> =20
> 
> In essence, I would state:
> 
> =20
> 
> A const qualifier may appear in front of any type as a way of
specifying
> that the argument must be statically computable at compile time.  This
> is strongly recommended for all parameters that will be used for delay
> or repetition values.  If const is used without a specific type, then
> the type is implicit.=20
> 
> =20
> 
> Any integer type can be used to pass delay and repetition values. For
> example, two equivalent ways of passing delay and repetition arguments
> are shown below:
> 
> =20
> 
>             sequence delay_arg_example ( const shortint delay1,
delay2,
> min, max);
> 
>             x  ##delay1   y[*min:max]   ##delay2  z;
> 
>             endsequence
> 
> =20
> 
>             `define my_delay=3D2;
> 
>             cover property ( delay_arg_example ( `my_delay,
`my_delay-1,
> 3, $) );
> 
> =20
> 
> which is equivalent to:
> 
> =20
> 
>      cover property ( x  ##2  y[*3:$]   ##1  z);
> 
> =20
> 
> =20
> 
> Of course I'd have to update the BNF too.
> 
> =20
> 
> Lisa
> 
> =20
> 
> =20
> 
> -----Original Message-----
> From: John Havlicek [mailto:john.havlicek@freescale.com]=20
> Sent: Tuesday, August 29, 2006 10:26 AM
> To: Lisa Piper
> Cc: sv-ac@eda-stds.org
> Subject: minor comments on 1549
> 
> =20
> 
> Hi Lisa:
> 
> =20
> 
> Below are a few minor comments (mostly editorial) on 1549.
> 
> =20
> 
> J.H.
> 
> =20
> 
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D
> 
> =20
> 
> - p. 3, 17.6.1 change.  I am confused by the use of "data type" in the
> context=20
> 
>   of=20
> 
> =20
> 
>      "The supported data types for sequence formal arguments are the
> types that
> 
>       are allowed for operands in assertion expressions (see 17.4.1)."
> 
> =20
> 
>   This suggests that the additional types "sequence" and "implicit"
are
> not=20
> 
>   data types.  However, later on p. 6 there is the statement
> 
> =20
> 
>      "The supported data types for property formal arguments include
all
> the=20
> 
>       types allowed for sequences plus the addition of the property
> type."
> 
> =20
> 
>   This suggests that all the sequence types are considered data types.
> 
> [Lisa Piper >>>] good catch.  I will change the latter to :=20
> 
> =20
> 
>       "The supported data types for property formal arguments include
> all the=20
> 
>       types allowed for sequences plus the addition of the property
> type."
> 
> =20
> 
> - Top of p. 4: =20
> 
> =20
> 
>      "For example, three equivalent ways of passing arguments ..." =20
> 
> =20
> 
>   I am a bit concerned with saying that these three are equivalent.
> 
>   They are not equivalent when the assignment rules for binding actual
> 
>   arguments to typed formal arguments are taken into account.  I
> 
>   prefer to say
> 
> =20
> 
>      "For example, three similar ways of passing arguments ..."
> 
> [Lisa Piper >>>] good point - done
> 
> =20
> 
>   Ways 2 and 3 really are equivalent.
> 
> =20
> 
> - p. 4.  Doron has written a separate comment about passing delay and
> repetition=20
> 
>   values to integer types with constant qualifier.  I think at this
time
> we should=20
> 
>   at least review the vision for this sort of argument passing.
> 
>   . As Doron points out, it will be nice to specify that the formal
> argument is=20
> 
>     for a compile-time constant expression since it is used in a delay
> 
>     or range value.
> 
>   . Using integer types means that we impose the assignment rules
of=20
> 
>     binding actual arguments to typed formal arguments.
> 
>   . I think we have understood that there is an exception to the
> assignment
> 
>     rule for binding when the actual argument is $.
> 
> =20
> 
> - p. 5.  I would change
> 
> =20
> 
>      "If the intent is to pass only the name of the signal of an
> event_expression ..."
> 
> =20
> 
>   to=20
> 
> =20
> 
>      "If the intent is to pass a signal that is not an entire
> event_expression ..."
> 
> [Lisa Piper >>>] done
> 
> =20
> 
> - p. 5.  In the example with sequence foo, operator associativity
makes
> the=20
> 
>   implicit parenthesization like this:
> 
> =20
> 
>      ( (1'b1, loc_a =3D a) ##0 (t =3D=3D loc_a)[*0:$] ) ##1 b
> 
> =20
> 
>   and so the [*0:$] cannot match 0 times due to the ##0 fusion.  I
> recommend=20
> 
> changing [*0:$] to [*1:$].
> 
> [Lisa Piper >>>] done
> 
> =20
> 
>