double_fpu_verilog

According to IEEE 754 standard, firstly, the floating-point number should be delivered which is nearest to the infinitely precise result; secondly, if there are two floating-point numbers who are equally near to the infinitely precise result, the one with an even significant digit shall be delivered. So in the source file called "fpu_round.v", there is a flag whose name is "round_nearest_trigger" . I think it's not suitable for the flag to only consider the bit mantissa_term1. Considering this two situations: mantissa_term3:0 = 00.10 is equally near to 00.00 and 01.00, so the 00.00 should be delivered; mantissa_term3:0=01.10 is equally near to 01.00 and 10.00, so the 10.00 should be delivered. But the flag "round_nearest_trigger" will cause 01.00 be delivered when mantissa_term3:0=00.10.

Yes, I think the rounder is incorrect. For example

• 64'h3ff9bffffff008d8 + 64'h3df0000080000000

The fpu delivers the result 64'h3ff9c000000008d9. But Softfloat and Warren Ferguson's Verilog Golden Models both deliver 64'h3ff9c000000008d8 when rounding to Nearest-Even. The fpu result is, I think, actually the Nearest-Away answer, which makes sense in light of YeJL's comment about mantissa_term1. You have, I believem, to maintain three further bits of precision not only two, in order to correctly distinguish the different cases.

Another example is

• 64'h3d6800340a070a00 + 64'hbf90200000000000

The fpu says the answer is 64'hbf901ffffffcfffa (for Nearest Even) but VGM says 64'hbf901ffffffcfff9, for both Nearest-Even and Nearest-Away in fact.

These two cases were discovered when using a formal verification tool.