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
> 
>