ISSUE 624

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