errata/489: parameters with signed but no range (3.11.1 and 12.2)

From: sharp@cadence.com
Date: Fri Oct 03 2003 - 19:15:50 PDT

  • Next message: Brad.Pierce@synopsys.com: "errata/488: PROPOSAL - 6.1.1, 12.3.3: output wire [3:0] o = 4'b1010 ;"

    Precedence: bulk

    >Number: 489
    >Category: errata
    >Originator: sharp@cadence.com
    >Environment:

    >Description:

    The two listed sections contain slightly different but
    apparently compatible rules for parameters with and without
    types in their declarations. One of the rules involves
    parameters with "a type specification, but no range
    specification". Here "type" apparently refers to "signed"
    (though this is confusing, since a parameter can also be
    declared as integer, real, realtime or time, which is a
    type but certainly doesn't need a range and shouldn't get
    one from elsewhere).

    The rules specify that in this case the parameter shall be
    of the type specified (i.e. a signed vector) but will get
    the range of the final value assigned. There are some
    problems with this "hybrid" declaration.

    In one place, it goes on to say effectively that if the
    final value is unsized, it gets an implementation-defined
    width of at least 32. This is badly specified, since it
    allows the implementation-defined width for such a parameter
    to be different from the implementation-defined width of an
    unsized constant. This is silly. It would have been
    better to leave this statement out, since an unsized
    constant already has an implementation-defined width of
    at least 32. This is just a special case of the parameter
    getting the width of the value assigned, which should be
    the width of an unsized constant, which is already defined.

    There is a worse problem. What happens if the value
    assigned is a real constant? The parameter is supposed
    to be the type specified, which is not real. So the
    parameter should not be real. However, since a real
    value is not a vector, it does not provide a width for
    the signed vector parameter.

    Frankly, I think that this "hybrid" of getting part of
    the type from the declaration and part of it from the
    value should have been left out. It is potentially
    confusing to users. I don't see any situation where it
    is particularly useful. It adds an extra rule to the
    already messy description of typed and untyped parameters.
    It is not consistent with the behavior of other declarations
    that include "signed" but no range (which apparently is
    considered a completely specified, if rather useless, type:
    a signed scalar). And it doesn't work if the value
    assigned turns out to be real.

    Possible solutions are to remove this special case, or
    clean up the descriptions and specify what happens if the
    value assigned is real.

    This archive was generated by hypermail 2.1.4 : Fri Oct 03 2003 - 19:22:48 PDT and
    sponsored by Boyd Technology, Inc.