| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 463
|
| Category | errata
|
| Synopsis | 4.1.13: Zero fill in ?: even if signed or x/z
|
| State | open
|
| Class | errata-discuss
|
| Arrival-Date | Sep 04 2003
|
| Originator | "Brad Pierce" <Brad.Pierce@synopsys.com>
|
| Release | 2001b: 4.1.10,4.1.13
|
| Environment |
See #8 and #106. |
| Description |
Section 4.1.13 says, regarding ( expression1 ? expression2 : expression3 ) that "If the lengths of expression2 and expression3 are different, the shorter operand shall be lengthened to match the longer and zero-filled from the left (the high-order end)." First, "(the high-order end)" should be deleted. More importantly, this behavior seems inconsistent with the rest of Verilog. The following example -- module m (output reg signed [31:0] o1, o2); initial begin o1 = ( 1'b0 ? 10'sb0000000000 : 10'sb1111111110 ) ; $displayb(o1); o2 = ( 1'b0 ? 10'sb0000000000 : 9'sb111111110 ) ; $displayb(o2); end endmodule yields 11111111111111111111111111111110 00000000000000000000000111111110 Was this really the intent? -- Brad |
| Fix |
|
| Audit-Trail |
From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com Cc: Subject: Re: errata/463: 4.1.13: Zero fill in ?: even if signed or x/z Date: Thu, 4 Sep 2003 18:33:05 -0400 (EDT) Brad, You are right that this is inconsistent with the rest of Verilog. It is also not what was intended. It is difficult to describe the full Verilog width-extension rules in simple English. Covering cases like compares (whose operands need to match in width, but whose result is always 1 bit), and conditionals (where the condition is self-determined, but the selected expressions aren't) makes the rules harder to describe. As a result, the text in the 1995 LRM described some simplified rules that apply to most operators, and then spelled out the behavior of compares and conditionals separately in the descriptions of those operators. The problem is that those descriptions were written before signed arithmetic was added in Verilog-2001. So they describe the unsigned case. And when the width-extension rules were generalized to cover signed arithmetic, those separate descriptions didn't get updated. So they are now wrong. I think that Shalom already reported the discrepancy on compares in a different erratum. Note also that the description in 4.1.13 is simplified in a different way. It doesn't take into account the possibility that the operator appears in a wider expression. So it only says that the shorter operand gets extended to match the wider operand. In fact, both operands are context-determined, and get extended to the width of the expression. This might be the same as the width of the wider operand, but it might not. There is not a 2-step process of extending to the width of the other operand using zero-extension, followed by extending to the width of the expression using normal rules for the signedness of the expression. There is just the normal process of extending both operands to the width of the expression, using the normal rules for the signedness of the expression. Steven Sharp sharp@cadence.com From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com Cc: Subject: errata/463: another similar error Date: Sat, 8 Nov 2003 16:23:18 -0500 (EST) I think these are mentioned in another erratum, but I want to make sure they don't get lost. There are other out-of-date references to zero- extending operands that should actually be sign-extended in signed expressions. See sections 4.1.7, 4.1.8, and 4.1.10. Steven Sharp sharp@cadence.com From: Shalom.Bresticker@motorola.com To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: errata/463: another sign-extension issue Date: Sun, 9 Nov 2003 08:00:36 +0200 (IST) Steven, > I think these are mentioned in another erratum, but I want to make sure > they don't get lost. There are other out-of-date references to zero- > extending operands that should actually be sign-extended in signed > expressions. See sections 4.1.7, 4.1.8, and 4.1.10. 4.1.7 is errata/8 (vsg-passed/lrm-draft) 4.1.8 is errata/106 (open) 4.1.10 is not dealt with in any other issue. However, I had assumed that zero-extension instead of sign-extension is the correct behavior for the bit-wise operators of 4.1.10. I have not checked what implementations actually do. -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: Shalom.Bresticker@motorola.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/463: another sign-extension issue Date: Sun, 9 Nov 2003 08:16:25 +0200 (IST) I would like to add a new sub-section to Section 4 which brings together all the information about bit-extension, whether zero- or x/z- or sign-extension, dealing with all the cases. Currently, each case is dealt with separately, and it does not work well. -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: Steven Sharp <sharp@cadence.com> To: sharp@cadence.com, Shalom.Bresticker@motorola.com Cc: etf-bugs@boyd.com Subject: Re: errata/463: another sign-extension issue Date: Thu, 13 Nov 2003 17:43:28 -0500 (EST) >4.1.10 is not dealt with in any other issue. >However, I had assumed that zero-extension instead of sign-extension is >the correct behavior for the bit-wise operators of 4.1.10. No, the rules in 4.5 should have superceded all of the various mentions of zero-extension left over from the 1995 standard. Unfortunately, 4.5 isn't really complete and fails to mention some operators that it should. It needs work. This issue is an example of why I don't like "clarifications" that duplicate information in more than one place in the standard. When something needs to be changed or extended later, some of that duplicate information doesn't get updated. Steven Sharp sharp@cadence.com From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com Cc: Subject: Re: errata/463: Re: errata/463: another sign-extension issue Date: Thu, 13 Nov 2003 17:46:15 -0500 (EST) > I would like to add a new sub-section to Section 4 which brings together > all the information about bit-extension, whether zero- or x/z- or > sign-extension, dealing with all the cases. > > Currently, each case is dealt with separately, and it does not work well. Sections 4.4 and 4.5 are supposed to cover this information. They need some work to make them more complete and clear, but this is their purpose. Steven Sharp sharp@cadence.com From: Shalom.Bresticker@motorola.com To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: errata/463: Re: errata/463: another sign-extension issue Date: Sun, 16 Nov 2003 15:18:31 +0200 (IST) > >4.1.10 is not dealt with in any other issue. > >However, I had assumed that zero-extension instead of sign-extension is > >the correct behavior for the bit-wise operators of 4.1.10. > > No, the rules in 4.5 should have superceded all of the various mentions > of zero-extension left over from the 1995 standard. Unfortunately, 4.5 > isn't really complete and fails to mention some operators that it should. > It needs work. > > This issue is an example of why I don't like "clarifications" that duplicate > information in more than one place in the standard. When something needs to > be changed or extended later, some of that duplicate information doesn't get > updated. I agree. So what is the correct behavior for the bit-wise operators? -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/463: another sign-extension issue Date: Sun, 16 Nov 2003 15:19:48 +0200 > > I would like to add a new sub-section to Section 4 which brings together > > all the information about bit-extension, whether zero- or x/z- or > > sign-extension, dealing with all the cases. > > > > Currently, each case is dealt with separately, and it does not work well. > > Sections 4.4 and 4.5 are supposed to cover this information. They need some > work to make them more complete and clear, but this is their purpose. I can agree with that. Possibly 4.4 and 4.5 should be combined, due to the mutual dependence between them. (The form of bit-extension (4.4) depends on signedness (4.5) and signedness depends on self-determinedness (4.4).) -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: Steven Sharp <sharp@cadence.com> To: sharp@cadence.com, Shalom.Bresticker@motorola.com Cc: etf-bugs@boyd.com Subject: Re: errata/463: Re: errata/463: another sign-extension issue Date: Mon, 17 Nov 2003 19:43:43 -0500 (EST) >So what is the correct behavior for the bit-wise operators? They behave like any of the other operators that don't have a special rule. They don't directly affect the signedness, but just follow the normal rules. Those rules are effectively: if any operand in the expression is unsigned, then the expression is unsigned. If all operands in the expression are signed, then the expression is signed. At the earliest point possible, operands are extended to the size of the expression. If the expression is signed, that is done with a sign-extension, else with a zero-extension. In a simple expression involving a bit-wise operator with two simple operands, the result of these rules is as follows. If both operands are signed, then they will be sign-extended to the width of the expression. Then the bit-wise operator will be applied. If either operand is unsigned, then both operands will be zero-extended to the width of the expression. Then the bit-wise operator will be applied. Steven Sharp sharp@cadence.com From: "Brad Pierce" <Brad.Pierce@synopsys.com> To: <etf-bugs@boyd.com> Cc: Subject: Re: errata/463: 4.1.13: Zero fill in ?: even if signed or x/z Date: Fri, 5 Aug 2005 16:17:12 -0700 The LRM doesn't seem clear about *when* the legs of a ?: are signed. By analogy with width in ?: and with signedness determination in case statements, I've assumed that whenever one leg of a ?: is unsigned, then the other leg is unsigned. But I don't find this spelled out explicitly in the LRM. -- Brad -----Original Message----- From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On Behalf Of Steven Sharp Sent: Thursday, September 04, 2003 3:40 PM To: etf-bugs@boyd.com Subject: Re: errata/463: 4.1.13: Zero fill in ?: even if signed or x/z Precedence: bulk The following reply was made to PR errata/463; 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/463: 4.1.13: Zero fill in ?: even if signed or x/z Date: Thu, 4 Sep 2003 18:33:05 -0400 (EDT) Brad, You are right that this is inconsistent with the rest of Verilog. It is also not what was intended. It is difficult to describe the full Verilog width-extension rules in simple English. Covering cases like compares (whose operands need to match in width, but whose result is always 1 bit), and conditionals (where the condition is self-determined, but the selected expressions aren't) makes the rules harder to describe. As a result, the text in the 1995 LRM described some simplified rules that apply to most operators, and then spelled out the behavior of compares and conditionals separately in the descriptions of those operators. The problem is that those descriptions were written before signed arithmetic was added in Verilog-2001. So they describe the unsigned case. And when the width-extension rules were generalized to cover signed arithmetic, those separate descriptions didn't get updated. So they are now wrong. I think that Shalom already reported the discrepancy on compares in a different erratum. Note also that the description in 4.1.13 is simplified in a different way. It doesn't take into account the possibility that the operator appears in a wider expression. So it only says that the shorter operand gets extended to match the wider operand. In fact, both operands are context-determined, and get extended to the width of the expression. This might be the same as the width of the wider operand, but it might not. There is not a 2-step process of extending to the width of the other operand using zero-extension, followed by extending to the width of the expression using normal rules for the signedness of the expression. There is just the normal process of extending both operands to the width of the expression, using the normal rules for the signedness of the expression. Steven Sharp sharp@cadence.com From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com Cc: Subject: Re: errata/463: 4.1.13: Zero fill in ?: even if signed or x/z Date: Fri, 5 Aug 2005 20:43:18 -0400 (EDT) If you ignore the obsolete text from v1995, and concentrate on the new rules in 4.5, I think it is clear enough. The legs of a ?: are context-determined, so you apply the rules in 4.5.1 (in slightly shortened form here) -- For non-self-determined operands the following rules apply: if any operand is unsigned, the result is unsigned if all operands are signed, the result will be signed, except as noted So if either leg is unsigned, the result is unsigned. Then you apply the rule in 4.5.2 that says -- Propagate the type and size of the expression back down to the context-determined operands of the expression. In general, any context-determined operand of an operator shall be the same type and size as the result of the operator. So if the result is unsigned, both operands are unsigned. Therefore, if either leg is unsigned, then so is the other. With this new text added to 4.5.2 in the 2005 draft, I think it is now spelled out. Steven Sharp sharp@cadence.com |
| Unformatted |
|
Hosted by Boyd Technology