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: Mon Apr 07 2003 - 15:00:01 PDT

  • Next message: Shalom.Bresticker@motorola.com: "errata/323: Some NOTES should be normative"

    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, Shalom.Bresticker@motorola.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: Mon, 7 Apr 2003 17:57:09 -0400 (EDT)

    >From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
     
    > Thus, the Notes in 2.5.1 and 3.9 which say that unsized constants and integer
     variables must be at least 32
    > bits are not officially binding parts of the standard.
     
     Interesting. I don't think that was the intention of the authors.
     
     
    > I accept that as the intention. But strictly speaking, the LRM does not define
     the "innate size" of unsized
    > constants or expressions when they are parts of context-determined
     expressions, only when they are
    > self-determined.
     
     Which makes the title of Table 29 the closest one can describe to that
     intended concept.
     
     
    > Third, there is a NOTE in 9.5 ("case statement"):
    > "NOTE--The default length of x and z is same as the default length of an
     integer."
    >
    > This sentence is hard to understand, because x and z cannot occur alone.
    > Presumably the intention was to refer to unsized constants where the
     high-order bit is x or z.
     
     I looked back for the history behind this note.
     
     In the Verilog-XL Reference Manual, the text states
     
     "The length of all the case item expressions, as well as the controlling
     expression in the parentheses, will be made equal to the length of the
     longest <case_item> expression. The most common mistake made here is to
     specify 'bx or 'bz instead of n'bx or n'bz, where n is the bit length of
     the expression in parentheses. The default length of x and z is the word
     size of the host machine, usually 32 bits."
     
     Clearly, x and z should have been 'bx and 'bz, and the note is explaining
     why that common mistake gives the wrong length.
     
     In the OVI standard, the last sentence got moved into a note. In the
     1995 IEEE standard, the sentence about the common mistake got removed,
     leaving the note stranded and even harder to decipher. I would suggest
     that it be removed, unless the accompanying text about the common mistake
     is added back, in which case it should be fixed to say 'bx and 'bz.
     
     Even the statement about the length isn't quite right. It should be
     "made equal to the length of the longest of the <case_item> expressions
     or the controlling expression." In other words, they are all made equal
     to the longest of all. If the controlling expression is longer than all
     of the case_items, then that length is used.
     
     Steven Sharp
     sharp@cadence.com
     

    This archive was generated by hypermail 2.1.4 : Mon Apr 07 2003 - 15:00:50 PDT and
    sponsored by Boyd Technology, Inc.