Re: errata/321: Table 29, 4.1.14, 2.5.1(3) , 3.9 -- size of unsized numbers and integer variables

From: Steven Sharp (sharp@cadence.com)
Date: Sat Apr 05 2003 - 16:30:03 PST

  • Next message: Shalom.Bresticker@motorola.com: "errata/322: 14.5, para. 2: "Figure 40" should be "Figure 39""

    Precedence: bulk

    The following reply was made to PR errata/321; it has been noted by GNATS.

    From: Steven Sharp <sharp@cadence.com>
    To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com
    Cc:
    Subject: Re: errata/321: Table 29, 4.1.14, 2.5.1(3) , 3.9 -- size of unsized numbers and integer variables
    Date: Sat, 5 Apr 2003 19:29:08 -0500 (EST)

    >According to Table 29, an unsized constant number is a self-determined
    >expression with the same bit length as an integer.
     
     No. The table is giving the size _if_ it is a self-determined expression.
     In other words, it is giving the innate size in the absence of any influence
     outside the expression being described. The table in the 1995 standard
     just said "expressions". It must have gotten changed to "self-determined
     expressions" because somebody pointed out that these may not end up being
     the final sizes in context-determined expressions.
     
    >According to a Note in 3.9, "Implementations may limit the maximum size
    >of an 'integer' variable, but they shall be at least 32 bits." This seems
    >to suggest that there is not conceptually any maximum size and that a bignum
    >implementation would match the semantics as well as or better than an
    >implementation with C-style ints.
     
     No, they are just like C ints: a fixed size variable whose size can be
     decided by the implementor, but which must be at least 32 bits.
     
    >Could one
    >think of unsized numbers and integers as having an effectively infinite
    >bit length?
     
     No, you are trying to read too much into this. They have a finite bit
     length, which is not specified by the standard except that it must be at
     least 32 bits. In practice, they are 32 bits, but an implementation that
     used more would still be compliant.
     
    > For example, if 'sb1 were assigned to a register, no matter
    >how long the register, it would be filled with 1 bits?
     
     No. Assuming that the implementation is using 32 bits for integers,
     'sb1 is equivalent to 32'sb1 or 32'sb00000000000000000000000000000001.
     There is a special rule for filling with x or z if that is the upper
     bit specified for an unsized constant, but there is no such rule for 1.
     Given that 32-bit signed constant, assigning it to a wider register would
     be a context-determined situation, and the constant would be sign-extended
     to the width of the register. Since the uppermost bit is 0, that will
     fill all but the lowest bit with 0.
     
    > Is there any
    >difference between 'sb1 and 1?
     
     Effectively no. They are both unsized signed constants, just in different
     bases.
     
    >What does it mean then to say that the number of bits "shall be at
    >least 32"?
     
     It means the implementation cannot treat them as 16-bit objects, but it
     could treat them as 64-bit objects if desired.
     
    > I guess this is to allow integers to be implemented as
    >C-style ints instead of as bignums, but I don't see the relevance to
    >'b0, 'b1, 'sb1 and 'sb0.
     
     I would say that the relevance is that while they each have an unspecified
     size, it must be the same size for both.
     
    >According to 4.1.14, "Unsized constant numbers shall not be allowed in
    >concatenations. This is because the size of each operand in the
    >concatentation is needed to calculate the complete size of the
    >concatenation."
    >
    >I take this to mean that not only would {'b0, 'b1} and {2{'b0}} be
    >disallowed, so also would be { ~'b0 , ~'b1 } and {2{~('b0')}}.
    >Likewise, not only { 1, -1} and {2{-1}} would be disallowed, but so
    >also would be { 1'b1 + 1 } and {2{1'b1+1}}. Is that interpretation
    >correct?
     
     In theory, that should be correct. In practice, Verilog-XL only seems to
     check for the simple case of unsized constants used directly as an operand
     of a concatenation. Most implementations have followed suit, in order to
     maintain backward compatibility. In fact, {2{-1}} gets allowed because
     -1 is not parsed as a number (no matter what the says). It is
     parsed as a unary minus operator applied to a number. I believe that VCS
     is even less strict in its checks, resulting in requests for other tools
     to relax their checks further also.
     
     Steven Sharp
     sharp@cadence.com
     

    This archive was generated by hypermail 2.1.4 : Sat Apr 05 2003 - 16:30:54 PST and
    sponsored by Boyd Technology, Inc.