| 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-Date | Apr 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