lundgren, david

double_fpu_verilog

There seems to be a bug in the exception logic during a multiply operation.  An inexact condition from the previous operation can affect the value of out during the first cycle after ready asserts.  Either the exception logic is incompletely flushed from the previous op, or the ready and out signals for the new operation are one cycle premature.

Incomplete flush of exception logic

Latency seems to be larger than reported in the overview.  Measuring from enable active on a rising clock edge to ready rising, I get the following with the non-pipelined version:

Add = 25
Sub = 26
Mul = 29
Div = 76

Please update latency numbers

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_term[1]. Considering this two situations: mantissa_term[3:0] = 00.10 is equally near to 00.00 and 01.00, so the 00.00 should be delivered; mantissa_term[3: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_term[3:0]=00.10.

Browse

double_fpu_verilog