pulp-platform / fpu_div_sqrt_mvp Goto Github PK

Hello,

I am sorry to disturb you.
The control_mvp in fpu_div_sqrt_mvp has undriven signals.
The local parameter Iteration_unit_num_S is set to 2'b10 in the file defs_div_sqrt_mvp.sv, this makes Q_sqrt3 is undriven ( Q_sqrt3 is only driven when Iteration_unit_num_S is 2'b11 ).
But the Q_sqrt_com_3 uses Q_sqrt3.

Can I ignore this spyglass Error ?

Bug Description

When executing the fsqrt.d instruction on a double-precision floating-point value representing positive infinity (0x7ff0000000000000), the Overflow (OF) flag in the fflags register is erroneously set. According to the IEEE 754 standard and the RISC-V specification, the fsqrt.d operation should not lead to an overflow situation when the input is infinity. This also results in inconsistency with Spike's output

Expected Behavior:
The OF flag in the fflags register should remain clear (i.e., not set) after performing a square root operation on an infinite value, as the result is well-defined and should be positive infinity.

Actual Behavior:
The OF flag is set in the fflags register, indicating an overflow, which contradicts the expected behavior defined by the IEEE 754 standard and RISC-V floating-point operation guidelines.

Steps to Reproduce:

1. Load a double-precision floating-point register with the value 0x7ff0000000000000 (positive infinity).
2. Execute the fsqrt.d instruction on this register.
3. Check the fflags register; observe that the OF flag is incorrectly set.

see: openhwgroup/cva6#2058

Looks like this line is missing a "Div_enable_SI&&"

I have been using the Imperas RISCV Tests included with riscvOVPsim for compliance testing and having some queries on the F ISA extension tests.

OVPSim : https://github.com/riscv-ovpsim/imperas-riscv-tests
F ISA test download page: https://www.ovpworld.org/library/wikka.php?wakka=riscvOVPsimPlus

These tests from Imperas are the updated RISCV Compliance tests and the fpnew is have some mismatches on the FDIV, FMUL and FSQRT tests.

Here are the mismatching calculations:
FPNEW_MISMATCH_COMPLIANCE.xlsx

I have only seen F ISA extension tests pass with the models (e.g. C/BFM), so this suggests there is a mismatch between the RTL and models.

Can you comment on my findings?

FDIV and FSQRT rounding mode calculation mismatches found when comparing the results from FPnew to a RocketChip RISCV IMAF processor.

I have attached a few examples of calculation mismatches found:

FDIV FSQRT Rounding Mode Calculation Mismatches .xlsx

Note: I have added the solution from issue openhwgroup/cvfpu#47 since it fixed rounding mode issues found when testing against the RISCV Compliance tests, and I have found there are less rounding mode issues detected with it included.

Can you comment on my findings?

@florent-gwt

Hello!

It looks like the FPU is not rounding infinity.
For example:

Rounding: RTZ
instr: fdiv.d f15, f10, f09
Operand (f09): 0x00000000b2489191 ('3.27244e+38')
Operand (f10): 0x47eec61b8652dbd0 ('1.4778e-314')
Expected (f15): 0x7fefffffffffffff ('1.79769e+308')
CVA6:                 0x7ff00000000000000

Hi, I'd just like to point out that division by power of 2 (operand B !=0, explicit mantissa=0) can be determined completely by the exponent subtraction-- no need to go through the iterations or normalization/rounding (although Infinity and subnormal results still need to be detected).

Similar for sqrt when operand is an even power of 2.

Thanks, Al Martin

line#2353 of /fpu_div_sqrt_mvp/hdl/control_mv.sv

iteration_div_sqrt_mvp #(C_MANT_FP64+6) iteration_div_sqrt
(
.A_DI (Iteration_cell_a_D[i] ),
.B_DI (Iteration_cell_b_D[i] ),
.Div_enable_SI (Div_enable_SI[i] ),
.Div_start_dly_SI (Div_start_dly_SI[i] ),
.Sqrt_enable_SI (Sqrt_enable_SI[i] ),
.D_DI (Sqrt_DI[i] ),
.D_DO (Sqrt_DO[i] ),
.Sum_DO (Iteration_cell_sum_D[i] ),
.Carry_out_DO (Iteration_cell_carry_D[i] )
);

While using this FPU in single precision is it still valid to use C_MANT_FP64+6 parameter in iteration_div_sqrt_mvp ? Is this not consume a lot of unnecessary resources while in single precision?

Hello!

For some inputs, the underflow (UF) flag is set but not the inexact (NX) flag.

Here is an example that triggers this bug:

Rounding: RTZ
instr: fdiv.d f15, f10, f09
Operand (f09): 0xc268a20e00000000 ('-8.46384e+11')
Operand (f10): 0x000000000828d569 ('6.76345e-316')
Expected (f15): 0x8000000000000000 ('-0')
Floating ouptuts match.
Fflags:
  Expected:    11 UF, NX
  Received:    10 UF

Hello!

I remarked that the rounding modes to -infinity and +infinity are inverted.

Kind regards,
Flavien

Hello!

The IEEE-754-2019 standard specifies that div(0,0) is an invalid instruction and therefore should not raise the divide by zero (DZ) flag.

You can test it for example with the pseude-assembly:

ft0 = 0x0000000000000000
ft1 = 0x0000000000000000
fdiv.d ft2, ft1, ft0

Hi,

We're doing a simple test of the VFDIV instruction with different round mode.A very large data div a small data shoule be a Inf data by IEEE-754, and it is pass when round mode is RNE. However, when I change the round mode to RTZ, it will Failed compare with Spike.
Below is the test case, and it look like a Bug in the div_sqrt_top_mvp.sv, because when i use a trust IP module, it will be passed.

double d_scalar;
volatile uint32_t vv8_reg = 0x00800000;
CHANGE_RM(RN_RTZ);
VSET(1, e32, m1);
VLOAD_32(v16, 0xc49a6333);

BOX_FLOAT_IN_DOUBLE(d_scalar, vv8_reg);
asm volatile("vfdiv.vf v24, v16, %[A]" ::[A] "f"(d_scalar));

Hello!

It appears that hdl/norm_div_sqrt_mvp.sv sometimes fails to detect inexact divisions with finite outcome.
This has two immediate consequences:

• The NX flag is sometimes 0 when it should be 1. I have so far never observed the reverse behavior (1 instead of 0).
• Rounding fails to happen when the result is inexact but the module takes it for exact.

Kind regards,
Flavien