I agree with Steven. For example, a tool that doesn't compute a "test_bit" of 1 in the following example simply has a bug. module test(test_bit); output test_bit; assign test_bit = ( (3'sb110 >>> 1) == (1'b1 + 1'b1 + 1'b1) ); initial #1 $display(test_bit); endmodule -- Brad -----Original Message----- From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Rich, Dave Sent: Thursday, November 01, 2007 6:47 PM To: Steven Sharp Cc: sv-ac@eda.org; sv-bc@eda.org Subject: RE: [sv-ac] Re: [sv-bc] Re: if-else I already checked our implementation, and it agrees with my interpretation, independently by the way. (At least someone did) The rules you quoted are now in 11.7.2 and I would say they are weak because by that step, the signedness has already been determined. It also conflict's with what's in 11.4.5. I interpret the rules in 11.4.5 to apply to any expression and not a simplification that only applies to simple operands. But let's get agreement on what the behavior SHOULD be and then argue what should be written in the LRM. I think each side should be evaluated in a self-determined context and then the rules in 11.4.5 should apply. > -----Original Message----- > From: Steven Sharp [mailto:sharp@cadence.com] > Sent: Thursday, November 01, 2007 6:20 PM > To: sharp@cadence.com; Rich, Dave > Cc: sv-ac@eda.org; sv-bc@eda.org > Subject: RE: [sv-ac] Re: [sv-bc] Re: if-else > > > >You seem to have a different interpretation of what a correct > >implementation should be. :) > > > >I think you are incorrectly determining that the result of the > >arithmetic shift should be unsigned. That would be true in the case of > >an arithmetic or relational operation, but not in the case of equality. > >Equality has its own explicit rules for dealing with signedness. > > I re-checked the 1364-2005 standard, and we actually put in a pretty > good description of the full rules for the relational and equality > operators. In 5.5.2 it says > > "However, there are two exceptions: > > -- The relational and equality operators have operands that are neither > fully self-determined nor fully context-determined. The operands > shall affect each other as if they were context-determined operands > with a result type and size (maximum of the two operand size) > determined > from them. However, the actual result type shall always be 1 bit > unsigned. The type and size of the operand shall be independent of > the rest of the expression and vice versa." > > So if you have a signed and unsigned operand, they affect each other as > if they were context-determined operands with an unsigned result type. > That means that the unsignedness gets propagated down into them by the > usual rules for context-determined operands. The results that I described > then follow. > > You might want to test your own implementation on this... > > Steven Sharp > sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Nov 1 23:13:44 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 01 2007 - 23:15:17 PDT