From: Steven Sharp (firstname.lastname@example.org)
Date: Mon Apr 07 2003 - 15:00:01 PDT
The following reply was made to PR errata/321; it has been noted by GNATS.
From: Steven Sharp <email@example.com>
To: firstname.lastname@example.org, Shalom.Bresticker@motorola.com
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
Which makes the title of Table 29 the closest one can describe to that
> 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
> 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.
This archive was generated by hypermail 2.1.4
: Mon Apr 07 2003 - 15:00:50 PDT
sponsored by Boyd Technology, Inc.