Re: [sv-ac] another small flaw in 1549 Annex F

Hi Manisha:

O.k., then we need a technical proposal for how to treat
$ as a typed entity.  What value will represent $?  How
will it behave in comparisons?  What are the casting 
rules for $?  Into what data containers can $ be placed?

J.H.

> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Tue, 2 Oct 2007 22:58:42 -0700
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] another small flaw in 1549 Annex F
> Thread-Index: AcgENOS+kRL47cPnTLiU4rFfO5L6+ABSn+Gg
> From: "Kulshrestha, Manisha" <Manisha_Kulshrestha@mentor.com>
> Cc: <sv-ac@eda-stds.org>
> X-OriginalArrivalTime: 03 Oct 2007 05:58:45.0317 (UTC) FILETIME=[755FF750:01C80582]
> 
> Hi John,
> 
> I feel that by putting this limitation we are encouraging usage of
> untyped formals (now with the introduction of more typed formals it
> should be other way around). Since a property writer may not know
> whether a user will ever pass a '$' for the range, he/she is forced to
> keep the upper bounds for these as untyped args.=20
> 
> Thanks.
> Manisha
> 
> -----Original Message-----
> From: John Havlicek [mailto:john.havlicek@freescale.com]=20
> Sent: Monday, October 01, 2007 7:41 PM
> To: shalom.bresticker@intel.com
> Cc: john.havlicek@freescale.com; Kulshrestha, Manisha;
> sv-ac@eda-stds.org
> Subject: Re: [sv-ac] another small flaw in 1549 Annex F
> 
> Hi Shalom:
> 
> Maybe there has not been criticism of the example of assigning $ to
> an int parameter. =20
> 
> However, I still do not think that there is agreement on how to cast $
> into a type or whether to treat it as a "special value" that is not
> really cast. =20
> 
> We discussed this in a recent SV-AC meeting and my recollection is
> that people did not think it was worth trying to define passing $ as
> actual argument to a typed sequence or property formal argument at
> this time.
> 
> Below are some comments from Gord in one of the notes on 1350.
> 
> J.H.
> 
> ----------------------------
> 
> 
> From Gord (Mar 13):
> 
> This note is a summary of some issues that were discussed today in
> SV-BC. Since this impact EC and AC issues, BC agreed this should go
> out for general discussion.
> 
> There are numerous issues with the current descriptions regarding
> passing $ as a parameter value. In particular, in 6.3.2.1, we have:
> 
>       The value $ can be assigned to parameters of integer types.
>       A parameter to which $ is assigned shall only be used
>       wherever $ can be specified as a literal constant.
> 
> A minor issue is that "integer" was likely meant to be "integral".
> 
> In the first example in 6.3.2.1, there is a generate condition:
> 
>       if ( max_quiet =3D=3D 0) begin
> 
> with an instantiation of the module where "max_quiet" is $.
> 
> 
> There are numerous questions regarding this and other contexts for
> parameters which denote $.
> 
> 1) Is a parameter denoting $ valid in a comparison expression? The
>     example indicates that it is, but there are no semantics.
> 
> 2) Is a parameter denoting $ valid as an operand in other expressions?
>     For example would "max_quiet + 1" be valid if max_quiet is $?
> 
> 3) Do $right, $left, $bits, etc have defined results for a
>     parameter which denotes $?
> 
> 4) The intent of $ appears to be to allow $ to be used in assertions.
>     But there are other contexts where $ is valid but means different
>     things. For example, $ is used to denote a dynamic array
> declaration,
>     the last element of a queue, and range bounds of covergroup
>     bins expressions. Was the intent to allow parameters that denote
>     $ in all such scenarios? There are some implementation impacts
>     of such a generalization that were likely not considered
>     originally.
> 
> 5) Can a parameter which denotes $ propagate down through other
>     parameters?
> 
> 6) What is the meaning of $ if it propagates through a typed
>     parameter? Is it the "last value of the range" or is it
>     a special value which retains the $ meaning? In particular,
>     if $ propagates from a 32-bit parameter to an 8-bit and then
>     back to a 32-bit parameter, does it still represent the
>     "last value in a 32-bit range" when used in a range context
>     (such as a covergroup bins).
> 
> 7) Depending on some of the above, the discussion of "$" as
>     "unbounded" is problematic since in some contexts it really
>     means "last value" or has other meanings.
> 
> 
> 
> My personal suggestion is that some of the issues could be resolved by
> the rule such as:
> 
>     A parameter that denotes $ may only be used in the following
> contexts:
>        a) a context in which $ is valid as a primary
>        b) as an actual to $unbounded
>        c) as the parameter value in a parameter assignment or override
>     A parameter which denotes $ continues to denote $ without regard
>     to the type of the integral parameter to which it is assigned.
> 
> This does not address the other meanings of $ in array and queue
> contexts.
> 
> Personally, I would very much prefer to disallow use of a parameter
> which denotes $ in array and queue contexts. Such use is much too
> close to a "macro substitution" view and can change the "natural"
> meaning of a type from a parametrically determined array size to a
> dynamic array.
> 
> I would like to see a restriction that a parameter denoting $ should
> only be legal in a range expression which admits $. This would involve
> assertion sequences and covergroups. This, I think, covers the
> original intent without introducing issues that we haven't thought
> about and that might be somewhat problematic in terms of
> implementation.
> 
> 
> > X-ExtLoop1: 1
> > X-IronPort-AV: E=3DSophos;i=3D"4.21,217,1188802800";=20
> >    d=3D"scan'208";a=3D"290369526"
> > X-MimeOLE: Produced By Microsoft Exchange V6.5
> > Content-class: urn:content-classes:message
> > Date: Mon, 1 Oct 2007 15:56:31 +0200
> > X-MS-Has-Attach:=20
> > X-MS-TNEF-Correlator:=20
> > Thread-Topic: [sv-ac] another small flaw in 1549 Annex F
> > Thread-Index: AcgEHoGKPwLMry4NRDWs9SPp9KpLeQAEL5zg
> > From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> > Cc: <sv-ac@eda-stds.org>
> > X-OriginalArrivalTime: 01 Oct 2007 13:56:32.0311 (UTC)
> FILETIME=3D[DF689C70:01C80432]
> >=20
> > John,=3D20
> >=20
> > > There is not general agreement on how to cast $ into a type=3D20
> > > or whether to treat it as a "special value" that is not=3D20
> > > really cast.  There has been criticism of the example of=3D20
> > > assigning $ to an int parameter.
> >=20
> > I think the situation was the reverse.
> >=20
> > 6=3D2E20.2.1 says explicitly, "The value $ can be assigned to =
> parameters
> of
> > integer types."
> >=20
> > The question would be about other types.
> >=20
> > Shalom
> > ---------------------------------------------------------------------
> > Intel Israel (74) Limited
> >=20
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.