[sv-bc] Issues with parameters which denote $

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.

Gord
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com