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

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. 

Thanks.
Manisha

-----Original Message-----
From: John Havlicek [mailto:john.havlicek@freescale.com] 
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.  

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.  

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 == 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=Sophos;i="4.21,217,1188802800"; 
>    d="scan'208";a="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: 
> X-MS-TNEF-Correlator: 
> 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=[DF689C70:01C80432]
> 
> John,=20
> 
> > There is not general agreement on how to cast $ into a type=20
> > or whether to treat it as a "special value" that is not=20
> > really cast.  There has been criticism of the example of=20
> > assigning $ to an int parameter.
> 
> I think the situation was the reverse.
> 
> 6=2E20.2.1 says explicitly, "The value $ can be assigned to parameters
of
> integer types."
> 
> The question would be about other types.
> 
> Shalom
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> 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.