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

I think that this has to be also considered together with 966.
ed 

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> Behalf Of John Havlicek
> Sent: Wednesday, October 03, 2007 7:44 AM
> To: Manisha_Kulshrestha@mentor.com
> Cc: john.havlicek@freescale.com; shalom.bresticker@intel.com; 
> sv-ac@eda-stds.org
> Subject: 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.
> 
> 

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