| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 624
|
| Category | errata
|
| Synopsis | Need clarification and resolution for extension rules
|
| State | open
|
| Class | errata-discuss
|
| Arrival-Date | Sep 22 2004
|
| Originator | Yong Xiao <yongx@tharas.com>
|
| Release | 2001b, IEEE P1364-2005/D3, 5/6/04
|
| Description |
Hi, There some ambiguous points about extension rules for relational op, eq op, bitwise op, logical op and reduction op. Errata 8 have the rules for relational op fixed. Errata 106 (about the rules for eq op) is open Errata 463 (about the rules for bitwise op) is open Errata 506 covers logical op and reduction op. Steve suggest that the operands for logical and reduction are self-determined, the results in 1-bit unsigned (if understand it correctly). Can we make resolution/fix for those open issues? Thanks. My personal opinion: we do not need paragraph about extension rules for relational op (Section 4.1.7), eq op (Section 4.1.8) and bitwise op (Section 4.1.10), just all refer to Section 4.4 and 4.5. And I agree what Steve suggested in Errata 506. Yong |
| Fix |
This issue was accidentally overwritten. I try to return it to its orginal subject. There is no proposal currently. |
| Audit-Trail |
From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, yongx@tharas.com Cc: Subject: Re: errata/624: need clarification and resolution for extension rules Date: Thu, 23 Sep 2004 17:55:37 -0400 (EDT) >Can we make resolution/fix for those open issues? Thanks. This will take some time and effort to get proper wording for the standard. If you need clarification of the intent before then, let us know and we can try to answer any questions you may have. Steven Sharp sharp@cadence.com From: Yong Xiao <yongx@tharas.com> To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: errata/624: need clarification and resolution for extension rules Date: Tue, 28 Sep 2004 10:20:25 -0700 Steven Sharp wrote: >>Can we make resolution/fix for those open issues? Thanks. >> >> > >This will take some time and effort to get proper wording for the >standard. If you need clarification of the intent before then, >let us know and we can try to answer any questions you may have. > >Steven Sharp >sharp@cadence.com > > > > Yes, we would like to know the intent of those rules (ie, width extension for eq, bitwise, logical, and reduction, and whether operand of reduction should be selfdetermined), if there is a consensus. Thanks. Yong From: "Brad Pierce" <Brad.Pierce@synopsys.com> To: "Yong Xiao" <yongx@tharas.com>, <etf-bugs@boyd.com> Cc: Subject: Re: errata/624: need clarification and resolution for extension rules Date: Tue, 28 Sep 2004 10:44:45 -0700 Yong, One way to move these issues forward would be to build a consensus by making formal proposals for issues 106, 463, and 506. http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=propose&pr=106 http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=propose&pr=463 http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=propose&pr=506 -- Brad From: Steven Sharp <sharp@cadence.com> To: sharp@cadence.com, yongx@tharas.com Cc: etf-bugs@boyd.com Subject: Re: errata/624: need clarification and resolution for extension rules Date: Tue, 28 Sep 2004 15:59:59 -0400 (EDT) >Yes, we would like to know the intent of those rules (ie, width >extension for >eq, bitwise, logical, and reduction, and whether operand of reduction should >be selfdetermined), if there is a consensus. You asked whether the operand of reduction should be self-determined. Table 29 clearly states in the entry for the reduction operators that "All operands are self-determined" (though it might be clearer if it said "i is self-determined", since there is confusion between the use of operand as "operand of an operator" versus the lowest level inputs to expressions defined as operands in 4.2). The operands of the logical operators (&&, ||) are self-determined. They were incorrectly grouped with the comparison operators in the table. This has already been fixed in the LRM. Since the inputs to the logical operators are effectively reduced to 1-bit truth values before being combined, there is no need for them to be the same size. Operands of the bitwise operators are context-determined (which is the default if table 29 does not say that they are self-determined). It should be clear that their operands need to end up the same size so that they can be combined bit-by-bit. The same applies to most of the arithmetic operators. Equality and relational operators are unusual. The operands are neither fully self-determined or context-determined. They affect each other, but are not affected by any other operands in the expression. Again, this makes sense. These two values need to be the same size in order to be compared. However, the result is a 1-bit truth value, so the individual bits of the two operand values don't need to interact with any bits outside the compare. This is described in the table by explicitly stating that the two operands are sized to the max length of the two operands. The old LRM dealt with this unusual case by explicitly describing the extension rules under these operators, rather than using the general rules involving self/context-determined expressions. Unfortunately, this text was written when there was only unsigned arithmetic, so it is incorrect for signed operands. Either this special text needs to be updated to cover signed operands, or the general rules need to be updated to account for the unusual "self-determined together" behavior of these operators. Neither will be pretty. The rules are pretty sensible and self-consistent. If an operand is self-determined, this generally goes both ways. If the operand is not extended to the size of the surrounding expression, then the surrounding expression is not extended to the size of the operand either (though it may be affected less directly by the size of the operand, as in concats). If the table says that the bit length is the max length of certain operands, you will see that those operands are also context-determined. If an operand's length is not included in such a max calculation, you will see that the operand is self-determined. (Note that a length of L(i) is the same as max(L(i)), so that counts.) All operands in context-determined expressions or sub-expressions are extended to the size of the context at the earliest possible point, to avoid any possible overflow. They do not wait until they are combined with the operand that caused the widest width. This does not match most other programming languages, so you need to pay attention to this. I believe that all of this is generally understood and accepted, so there should be no problem getting a consensus on this. Most of it comes directly from the behavior of Verilog-XL, which the initial LRM was intended to match. There has been some contention on the subject of signedness, because some people want it to work the way it does in other languages they know. However, because the size extension is done early, it CANNOT work the way those other languages do. No scheme that is backward compatible with the pre-existing early extension rules in Verilog can match those other languages' behavior. I can explain the intent of the existing rules, but you should be aware that some people believe that they should be changed. Steven Sharp sharp@cadence.com From: Yong Xiao <yongx@tharas.com> To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: errata/624: need clarification and resolution for extension rules Date: Tue, 28 Sep 2004 14:24:31 -0700 Hi, Steve: Thank you very much for your detailed clarification. My confusion was mainly coming from the text in 4.1.7, 4.1.8, and 4.1.10, where it says the operands for relational op, eq op, and bitwise op should be zero-extended. I searched the errate database, only errate 8 was fixed. Great that you make it clear. Also thanks for pointing out that the operands for eq op and relational op are neither self-determined nor context-determined. Yong Steven Sharp wrote: >>Yes, we would like to know the intent of those rules (ie, width >>extension for >>eq, bitwise, logical, and reduction, and whether operand of reduction should >>be selfdetermined), if there is a consensus. >> >> > > >You asked whether the operand of reduction should be self-determined. >Table 29 clearly states in the entry for the reduction operators that >"All operands are self-determined" (though it might be clearer if it said >"i is self-determined", since there is confusion between the use of >operand as "operand of an operator" versus the lowest level inputs to >expressions defined as operands in 4.2). > >The operands of the logical operators (&&, ||) are self-determined. They >were incorrectly grouped with the comparison operators in the table. This >has already been fixed in the LRM. Since the inputs to the logical operators >are effectively reduced to 1-bit truth values before being combined, there is >no need for them to be the same size. > >Operands of the bitwise operators are context-determined (which is the >default if table 29 does not say that they are self-determined). It >should be clear that their operands need to end up the same size so that >they can be combined bit-by-bit. The same applies to most of the arithmetic >operators. > >Equality and relational operators are unusual. The operands are neither >fully self-determined or context-determined. They affect each other, but >are not affected by any other operands in the expression. Again, this makes >sense. These two values need to be the same size in order to be compared. >However, the result is a 1-bit truth value, so the individual bits of the >two operand values don't need to interact with any bits outside the compare. >This is described in the table by explicitly stating that the two operands >are sized to the max length of the two operands. > >The old LRM dealt with this unusual case by explicitly describing the >extension rules under these operators, rather than using the general rules >involving self/context-determined expressions. Unfortunately, this text >was written when there was only unsigned arithmetic, so it is incorrect >for signed operands. Either this special text needs to be updated to cover >signed operands, or the general rules need to be updated to account for the >unusual "self-determined together" behavior of these operators. Neither >will be pretty. > >The rules are pretty sensible and self-consistent. If an operand is >self-determined, this generally goes both ways. If the operand is not >extended to the size of the surrounding expression, then the surrounding >expression is not extended to the size of the operand either (though it >may be affected less directly by the size of the operand, as in concats). >If the table says that the bit length is the max length of certain operands, >you will see that those operands are also context-determined. If an >operand's length is not included in such a max calculation, you will see >that the operand is self-determined. (Note that a length of L(i) is the >same as max(L(i)), so that counts.) > >All operands in context-determined expressions or sub-expressions are >extended to the size of the context at the earliest possible point, to >avoid any possible overflow. They do not wait until they are combined >with the operand that caused the widest width. This does not match most >other programming languages, so you need to pay attention to this. > >I believe that all of this is generally understood and accepted, so there >should be no problem getting a consensus on this. Most of it comes >directly from the behavior of Verilog-XL, which the initial LRM was >intended to match. > >There has been some contention on the subject of signedness, because some >people want it to work the way it does in other languages they know. >However, because the size extension is done early, it CANNOT work the >way those other languages do. No scheme that is backward compatible with >the pre-existing early extension rules in Verilog can match those other >languages' behavior. I can explain the intent of the existing rules, but >you should be aware that some people believe that they should be changed. > >Steven Sharp >sharp@cadence.com > > > > From: Steven Sharp <sharp@cadence.com> To: sharp@cadence.com, yongx@tharas.com Cc: etf-bugs@boyd.com Subject: Re: errata/624: need clarification and resolution for extension rules Date: Tue, 28 Sep 2004 19:23:36 -0400 (EDT) >My confusion was mainly coming from the text in 4.1.7, 4.1.8, and >4.1.10, where it says the >operands for relational op, eq op, and bitwise op should be >zero-extended. Yes, this is the text left over from the 1995 LRM, where there was no signed arithmetic. Even then it is overly simplistic, and only correctly describes the situation where the operands are simple ones, rather than expressions. It says that the operands will be zero-extended before the comparison, implying that they wait until then. The actual effect is to change the result width of the two operands, as with a context-determined operand. If they are themselves expressions, that width will propagate downward through operators with context-determined operands. This will result in extension before those operators, so the operands will already be matching widths before the comparison. The situation where the operands are simple ones is just a degenerate case of this, where the point where the operands get extended does happen to be just before the comparison. I searched the >errate database, only errate 8 was fixed. >Great that you make it clear. Also thanks for pointing out that the >operands for eq op >and relational op are neither self-determined nor context-determined. Glad that it helped. I like to view the comparisons as being composed of two steps: the first step is the comparison between the two operands, which therefore need to be the same width. The second step is producing a 1-bit truth value from that comparison. The operands of the first step are context-determined, but the hidden "operand" of the second step is self-determined. The "operator" in the second step isolates the two operands from the rest of the expression. This can be expressed explicitly in some cases: a!=b is equivalent to |(a^b) Here the ^ is the compare, whose operands are context-determined and therefore affect each other. However, the operand of the reduction-OR (which is the expression (a^b)) is self-determined, so neither a nor b will be affected by anything elsewhere in the expression. The a!=b works the same way, except that the intermediate result is hidden. Steven Sharp sharp@cadence.com Fix replaced by bineet.srivastava@st.com on Mon Oct 4 04:59:09 2004 Hi, In section 10.3.5 Use of constant functions (IEEE P1364-2005/D3, 5/6/04) 1) Any function invoked within a constant function shall be a constant function local to the current module. 2)* They shall not themselves use constant functions in any context requiring a constant expression. Point 2) needs to be explained , seems like contradicting 1) point. As suggestion, may be rephrased as They shall not themselves use constant functions in context of port/variable/net declaration requiring constant expression. Any comments?? regards bineet Fix replaced by bineet.srivastava@st.com on Mon Oct 4 05:00:20 2004 Hi, In section 10.3.5 Use of constant functions (IEEE P1364-2005/D3, 5/6/04) 1) Any function invoked within a constant function shall be a constant function local to the current module. 2)* They shall not themselves use constant functions in any context requiring a constant expression. Point 2) needs to be explained , seems like contradicting 1) point. As suggestion, may be rephrased as They shall not themselves use constant functions in context of port/variable/net declaration requiring constant expression. Any comments?? regards bineet Fix replaced by Shalom.Bresticker@freescale.com on Mon Oct 18 08:55:05 2004 This issue was accidentally overwritten. I try to return it to its orginal subject. There is no proposal currently. |
| Unformatted |
|
Hosted by Boyd Technology