Sign of Zero is wrong when multiplier_mode is on

[jingpu]

The bug happens when multiplier_mode is on (opcode=01). Result Z should be the product of A and B. A and B here are denorms with different sign bit, so the sign bit of expected result should be one.

Code version 753d51f
To reproduce:

git checkout 753d51f2b64f6089a2e12b7ea3969a133b33432b
make -f $FPGEN/Makefile run RUN=+NumTrans=1000 GENESIS_PARAMS="top_FPGen.FPGen.FMA.PipelineDepth=8 top_FPGen.FPGen.FMA.EnableMultiplePumping=YES top_FPGen.FPGen.FMA.MulpPipelineDepth=3 top_FPGen.FPGen.FMA.MulShift.MUL0.TreeType=ZM top_FPGen.FPGen.FMA.MulShift.MUL0.BoothType=3"

run log:

45500: Transaction #19: 
45500 opcode: 01
45501: SENT:   TypeA=Denorm001 SignA=0 ExpA=0x000 FracA=0x0000000000001
45501:         TypeB=DenormRnd SignB=1 ExpB=0x000 FracB=0x9a56aa235af86
45501:         TypeC=Random SignC=1 ExpC=0x333 FracC=0xf5ea79407a596
45501: EXPECTED: Type=Zero Sign=1 Exp=0x000 Frac=0x0000000000000
45501: FOUND:   Type=Zero Sign=0 Exp=0x000 Frac=0x0000000000000
45501: 0000000000000001x8009a56aa235af86+b33f5ea79407a596 = 0000000000000000 (8000000000000000) WRONG
 45501: ERROR Found

[jingpu]

This bug is due to the mismatch between hardware and gold model on the sign of result when C=0.

In gold model, the sign of result is the same as the sign of AB no mater C is pos zero or neg zero.

// file: verif/GoldFMA.vp 
// line:269
   // if C=0
   if(ExpC == 1 && ManC == {(`$frac_width+1`){1'b0}})begin
      ManSum = { ManProduct, 2'b0, {(`$frac_width+1`){1'b0}}};
      SignExpected = SignProduct;
      ExpSum = ExpProduct;
   end

In hardware, if both AB and C are zeros (ResultExactZero=1), then the sign of result is given by SignAB & SignC. Therefore, if C is pos zero (SignC=0), then the result will be pos zero.

// file: rtl/FMA_Add.vp 
// line:202
assign SignResult = ResultExactZero? SignAB & SignC : SignAB ^ SumSign;

I am not sure which one is the standard. Moreover, in the bug, it was actually a multiply operation. Right now, we hack multiply operation by pretending C=0, and I am not sure if the sign of C here should influence the sign of the result.

As a workaround in commit ee81703, I changed the checking in verification not to check the sign of zero results.

[shacham]

Jing, what does Multiplier_mode=on controls?

Ofer.

On Thu, Apr 25, 2013 at 2:55 AM, Jing Pu notifications@github.com wrote:

This bug is due to the mismatch between hardware and gold model on the
sign of result when C=0.

In gold model, the sign of result is the same as the sign of AB no mater C
is pos zero or neg zero.

// file: verif/GoldFMA.vp
// line:269
// if C=0
if(ExpC == 1 && ManC == {($frac_width+1){1'b0}})begin
ManSum = { ManProduct, 2'b0, {($frac_width+1){1'b0}}};
SignExpected = SignProduct;
ExpSum = ExpProduct;
end

In hardware, if both AB and C are zeros (ResultExactZero=1), then the sign
of result is given by SignAB & SignC. Therefore, if C is pos zero
(SignC=0), then the result will be pos zero.

// file: rtl/FMA_Add.vp
// line:202
assign SignResult = ResultExactZero? SignAB & SignC : SignAB ^ SumSign;

I am not sure which one is the standard. Moreover, in the bug, it was
actually a multiply operation. Right now, we hack multiply operation by
pretending C=0, and I am not sure if the sign of C here should influence
the sign of the result.

As a workaround in commit ee81703ee81703,
I changed the checking in verification not to check the sign of zero
results.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-16997874
.

[jingpu]

Multiplier_mode=on makes FMA do multiply operation. We start to find bugs now because previously we didn't seriously implement ADD and MUL operations. Multiplier_mode and adder_mode are there just for energy saving by gating the clocks of adder and multiplier respectively, and testbench didn't check the function.
Then we built some wrappers and muxes to funtionally implement ADD and MUL. Recent bugs are mostly about these logic.

[jingpu]

Multiplier_mode=on makes FMA do multiply operation. We start to find bugs
now because previously we didn't seriously implement ADD and MUL
operations. Multiplier_mode and adder_mode are there just for energy saving
by gating the clocks of adder and multiplier respectively, and testbench
didn't check the function.
Then we built some wrappers and muxes to funtionally implement ADD and MUL.
Recent bugs are mostly about these logic.

On Thu, Apr 25, 2013 at 8:42 AM, Ofer Shacham notifications@github.comwrote:

Jing, what does Multiplier_mode=on controls?

Ofer.

On Thu, Apr 25, 2013 at 2:55 AM, Jing Pu notifications@github.com
wrote:

This bug is due to the mismatch between hardware and gold model on the
sign of result when C=0.

In gold model, the sign of result is the same as the sign of AB no mater
C
is pos zero or neg zero.

// file: verif/GoldFMA.vp
// line:269
// if C=0
if(ExpC == 1 && ManC == {($frac_width+1){1'b0}})begin
ManSum = { ManProduct, 2'b0, {($frac_width+1){1'b0}}};
SignExpected = SignProduct;
ExpSum = ExpProduct;
end

In hardware, if both AB and C are zeros (ResultExactZero=1), then the
sign
of result is given by SignAB & SignC. Therefore, if C is pos zero
(SignC=0), then the result will be pos zero.

// file: rtl/FMA_Add.vp
// line:202
assign SignResult = ResultExactZero? SignAB & SignC : SignAB ^ SumSign;

I am not sure which one is the standard. Moreover, in the bug, it was
actually a multiply operation. Right now, we hack multiply operation by
pretending C=0, and I am not sure if the sign of C here should influence
the sign of the result.

As a workaround in commit ee81703<
ee817032ba9df17456400238a3b253f9e5e77363>,

I changed the checking in verification not to check the sign of zero
results.

—
Reply to this email directly or view it on GitHub<
https://github.com/StanfordVLSI/FP-Gen/issues/2#issuecomment-16997874>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-17015014
.