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

Hi Arturo,

this is pretty well what we decided during our meeting today. Good
correlation.
Except that this will be separated from 1549 into another item on mantis
and may include additional stuff regarding the other arguments, like
directionality.

ed 

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> Behalf Of Arturo Salz
> Sent: Tuesday, September 05, 2006 1:03 PM
> To: john.havlicek@freescale.com; Arturo.Salz@synopsys.COM
> Cc: piper@cadence.com; sv-ac@eda-stds.org
> Subject: 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=3
> D=3D=3D=3D
> =3D=
> >
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3
> D=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
> > 
> > 
> 
>