Re: [sv-bc] 6.20.2 Value parameters - proposal

>From: Greg Jaxon <Greg.Jaxon@synopsys.com>

>That section documents the very flexible way that parameters can acquire
>all _or_part_ of their type from a so-called "final assignment" to the 
parameter.
>I was, frankly, a little surprised by the partial typing aspect:

I have always opposed that part.  It is messy and confuses things.
Unfortunately, I didn't know about it until it was too late.

But the rules spell out exactly the situations that are treated as
having part of the type come from the value.  If anything else is
specified for the data type, then it does not fall into that special
case.  Therefore, the normal rules for determining the type should
be applied.


>It would be worth a non-normative note here saying that this implied
>range may have a different number of packed_dimensions, whose bounds
>might differ from those of the final assigned value.  Only ranges are
>implied, no struct, union or unpacked array type information
>is carried implicitly by the final assignment to a value parameter.

In 1800-2005 6.3.2, it says "If the expression is integral, the parameter
is a logic vector of the same size with range [size-1:0]."  Seems clear.
Did that get lost in the merge?


>"-- A parameter with no range specification, with either a signed type
>    specification or no type specification, and for which the final value
>    assigned to it is unsized shall have an implied range with an lsb
>    equal to 0 and an msb equal to an implementation-dependent value of at 
least 31."
>
>The term "range specification" is used throughout §6.20.2 without being 
defined.
>It must refer to the first packed_dimension, which is what the 1364 standard
>called a "range".  The editor may need to rework the prose here.
>
>§6.20.2 also omits any discussion of how to react to the presence of
>unpacked_dimension specifications.  If we compound the combinatorial 
enumeration
>of all the extra possibilities, this section will become tediously long,
>when I think the ideas are pretty simple:

Again, 1800-2005 6.3.2 talked about parameters without an explicit type
declaration.  You then have to look at 1364-2005 to recognize that this
includes the case where "signed" is specified without a range.  But it
would not include anything with unpacked dimensions.  In merging the two
LRMs, this may not have come out clearly.  

1800-2005 is clear that parameters without an explicit type declaration
cannot come out as anything but a real or a logic vector.  6.3.2 required
that in the assignment to, or override of, a parameter without an explicit
type declaration, the type of the expression assigned be real or integral.
If the expression is real, the parameter is real.  If it is integral, the
parameter is a logic vector.  Nothing else is possible.

In moving to explicit types on parameters, we had to continue to allow
the old implicitly typed parameters.  But I don't think there was any
intent to extend them indefinitely.  I think that the "partial types",
where signedness but not the range was specified, was a mistake.  It was
a failure to make a clean break with the old approach, so that a little of
it got extended.  Let that be the end of it.  Please :-)


>One option is to disallow the combination of implicit type or implied range
>when unpacked dimensions are specified in a parameter, localparam, or specparam
>declaration.  Simply report a syntax error and bail out.

I think this would be the intended answer.  Unpacked dimensions are part of
a data type, so a parameter declaration with unpacked dimensions would not
be a parameter without an explicit type declaration.


>The opposite option is to keep extending partly given, partly implied,
>typing of parameters so that all combinations make sense.  To do this, 
1800-2009
>would have to say:

This was clearly forbidden in 1800-2005.  I don't think there was any
intent to extend the implicitly typed parameters.  They are just there
for backward compatibility (and perhaps convenience in the common case
of integral types).



>Greg Jaxon wrote:
>
>> Does the unpacked_dimension after a parameter_identifier  impart some
>> implicit data type to that parameter?

Yes.  Since it has type information other than the specific cases allowed
for parameters without explicit data type, it follows the normal rules.


>> Specifically in the following, can values of any type and shape override
>> Moneypenny and Bond?
>> 
>> module Ian #( Moneypenny, Bond[0:7] ) ( inout integer frequency );
>> 
>> If Bond is "shapen, not typed", what forms and types of expression can
>> legally supply its value?

Moneypenny has no explicit type.  It must be overridden with a real or
integral value.  Bond is an unpacked array of 8 logic scalars.  It can
only be overridden by an assignment compatible array.

This looks a little irregular when you put them side-by-side in an example
like this one.  But why would you write your code this way except to try
to confuse someone with the apparent but incorrect parallels between the
two parameter types?  It is easy enough to code it clearly.  If you want
to make it clear what Bond is, make it "logic Bond[0:7]".

Anyway, shouldn't that be Bond[00:7]?

Steven Sharp
sharp@cadence.com


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