ISSUE 321

Add Proposal  Add Analysis  Edit Class, Environment, or Release
Number 321
Category errata
Synopsis Table 29, 4.1.14, 2.5.1(3), 3.9, 9.5 -- size of unsized numbers and integer variables
State open
Class errata-discuss
Arrival-DateApr 04 2003
Originator "Brad Pierce" <Brad.Pierce@synopsys.com>
Release 2001b: Table 29, 4.1.14, 2.5.1(3), 3.9, 9.5
Environment
Description
According to Note 3 of 2.5.1, "The number of bits that make up an unsized
number (which is a simple decimal number or a number without the size
specification) shall be at least 32."

According to Table 29, an unsized constant number is a self-determined
expression with the same bit length as an integer.

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. This would be consistent with another
paragraph of 3.9, which says "An 'integer' is a general-purpose variable
used for manipulating quantities that are not regarded as hardware
registers."

In what sense are unsized numbers self-determined expressions? Could one
think of unsized numbers and integers as having an effectively infinite
bit length? For example, if 'sb1 were assigned to a register, no matter
how long the register, it would be filled with 1 bits? Is there any
difference between 'sb1 and 1?

What does it mean then to say that the number of bits "shall be at
least 32"? 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.

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?

-- Brad

Fix
Audit-Trail

From: Stephen Williams <steve@icarus.com>
To: "Brad Pierce" <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/321: Table 29, 4.1.14, 2.5.1(3) , 3.9 -- size of unsized numbers and integer variables
Date: Fri, 04 Apr 2003 21:17:50 -0800

Brad.Pierce@synopsys.com said:
> 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?

Ah, you struck on a pet peeve of mine. I've been through the wringer
on this one, actually; I (Icarus Verilog) catch the cases you are
pointing out as errors. Some other Verilog compilers, however, accept
{15+1} as perfectly valid and I've therefore spent a great deal of
time arguing with various would-be bug reporters over this.

I therefore lobby that the standard explicitly say that operators with
unsized operands are themselves unsized. I believe that the standard
does already say as much in the roundabout way you suggest, but I think
it warrants explicit mention.

Also, we should resist the temptation to define integer variables as
exactly 32 bits. "At least 32bits" is as it should be, more bits should
be a legal implementation choice.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."



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


From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.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: Sun, 06 Apr 2003 18:11:43 +0300

Note: The IEEE Standards Style Manual says the following about "Notes":

"Explanatory statements may be used in the text for emphasis or to offer informative suggestions about the
technical content of the standard.These notes provide additional information to assist the reader with a
particular passage. A note in the text is NOT an official part of the approved standard and should follow that
paragraph to which it belongs."

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.


Second, Steven wrote about Table 29:
"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."

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.


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.


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


From: Shalom.Bresticker@motorola.com
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/321: Table 29, 4.1.14, 2.5.1(3) , 3.9 -- size of unsized
numbers and integer variables
Date: Wed, 9 Apr 2003 14:06:01 +0300 (IDT)

On Mon, 7 Apr 2003, Steven Sharp wrote:

> > 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.

Actually, the original title of Table 29, "Bit-lengths resulting from
expressions" tries to express that the bit-lengths appearing in the table are
the basis for computing the final bit-length of the expression.

> 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.

The 1364 LRM says, "The length of all the case item expressions, as well as the
case expression in the parentheses, shall be made equal to the length of the
longest case expression and case item expression.", which is trying to say the
right thing, but does not quite succeed.

Shalom

Unformatted




Hosted by Boyd Technology