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

Hi,

Yes, I agree that 1549 should not try to solve this problem. There are
already few mantis items on this issue. With sv-ac pushing 1601 (untyped
args), our assumption is that people have already started using typed
args as introduced in P1800. Although LRM is not very clear but it
definitely gave the impression that '$' can be passed as integer type.
Probably some property libraries have been written with this assumption.


I feel that we should not put any restrictions on the type of '$' and
let sv-bc resolve this issue. If they can not resolve it in the coming
LRM then it will work the way it works now (with the limitations
mentioned by Gordon).

What do others think ?

Thanks.
Manisha
-----Original Message-----
From: Lisa Piper [mailto:piper@cadence.com] 
Sent: Friday, October 05, 2007 6:07 AM
To: john.havlicek@freescale.com; Kulshrestha, Manisha
Cc: shalom.bresticker@intel.com; sv-ac@eda-stds.org
Subject: RE: [sv-ac] another small flaw in 1549 Annex F

John and Manisha,

I agree that it would be nice to define this, however not in 1549. The
definition should be general enough to apply to "$" both inside and
outside of assertion context, and should therefore be kept in an
isolated proposal. Even if we define it for assertions only, the
champions will likely bounce it until SV-BC has a chance to generalize
it in a way that applies to any $, similar to our default disable iff
proposal. If this is added to 1549, it will likely mean that it, and all
the other changes of 1549, will have to be reviewed and approved by
SV-BC as well. 

This was an existing issue that I feel strongly should be handled by an
isolated Mantis item.

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