[sv-bc] 6.20.2 Value parameters - proposal

In addition to repairing the typos in the BNF for parameter declarations,
in §6.20.1, ¶9 & ¶11, more semantic rules are needed in §6.20.2.

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:

"-- A parameter with no range specification and with either a signed type
    specification or no type specification shall have an implied range
    with an lsb equal to 0 and an msb equal to one less than the size
    of the final value assigned to the parameter."

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.

"-- 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:

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.

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:

"-- A parameter with unpacked_dimension(s), and no user-defined or built-in
    data type or packed_dimension(s), and either with or without a signing
    specification, shall have an implied packed_dimension with an lsb equal to 0
    and an msb equal to one less than the ratio of the size of the final value
    to the unpacked element count of the declared parameter, rounded up to
    a whole number.  The final assigned value shall be sign or 0 extended to
    a multiple of the unpacked element count in accordance with the signedness
    declared for the parameter (the default being unsigned, as usual) and then
    bit-stream cast into the declared and implied parameter type"

These are the only two options easily supported by the separate compilation
and linkage systems most often used to send raw parameter information
through a design hierarchy.  Very little type safety is available in the
world of hybrid language linkages.

Greg Jaxon





Greg Jaxon wrote:

> Does the unpacked_dimension after a parameter_identifier  impart some
> implicit data type to that parameter?
> 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?



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