05-19-2021, 07:19 AM

Hi,

I ran the cv32e40p (RI5CY) core with FPU (floating point) enabled and tried to check the result for all the floating-point operations. I have faced the following issues in case of division and fused operations.

These are the inputs I have given. All the following data is for 32-bit FPU, input1, input2, input3, output, and the expected output are represented in {1-bit sign, 8-bit exponent, 23-bit mantissa}, and status and expected status are represented as {Invalid, Divide by Zero, Overflow, Underflow, Inexact}

Division:

Input1 - 1_10000010_11011100000100010010000

Input2 - 1_00000001_11110010110000000000000

Out - 0_11111111_00000000000000000000000

Expected out - 0_11111110_11111111111111111111111

Status - 00100

Expected status - 00001

Rounding mode - RTZ (Round to Zero)

Operation - Division

The Input1 is being divided with Inp2 which is a very large number, the result should overflow and give infinity as the output, but as the rounding mode is RTZ (round to zero), the output should be the maximum possible number in a 32-bit floating-point number instead of infinity.

Input1 - 0_00000000_00000000000000000000000

Input2 - 1_11111111_00000000000000000000000

Out - 1_00000000_00000000000000000000000

Expected out - 1_00000000_00000000000000000000000

Status - 00100

Expected status - 00000

Rounding mode - RTZ (Round to Zero)

Operation - Division

0/Inf is giving overflow status even though the output is not infinity

Input1 - 0_01111110_11100000000000000000000

Input2 - 0_01111111_00000000000000000000001

Out - 0_01111110_01111111111111111111111

Expected out - 0_01111110_01111111111111111111110

Status - 00001

Expected status - 00001

Rounding mode - RDN (Round Down)

Operation - Division

The expected data is 0_01111110_01111111111111111111110 but getting output as 0_01111110_01111111111111111111111, both the inputs are positive and the rounding mode is round down, so the output shouldn't be changing because of the rounding mode

Fused Multiply Add:

Input1 - 0_00000000_00000000000000000000000

Input2 - 0_00000000_00000000000000000000000

Input3 - 0_00100100_00101010011010100100100

Out - x_xxxxxxxx_xxxxxxxxxxxxxxxxxxxxxxx

Expected out - 0_00100100_00101010011010100100100

Status - 000xx

Expected status - 00000

As input1 and input2 are 0, the output should be input3, but getting X from the core whenever any one of the inputs is 0 for fused operations.

Please let me know if these are the bugs in the core or the FPU, or if there's anything wrong with my understanding of floating-point operations.

I ran the cv32e40p (RI5CY) core with FPU (floating point) enabled and tried to check the result for all the floating-point operations. I have faced the following issues in case of division and fused operations.

- Rounding mode output is incorrect for division, rounding mode for the division is not the same as addition, subtraction, and multiplication

For example, when rounding mode is RTZ (round to zero), the guard, round and sticky flags aren't ignored and the final output is changed by 1 bit.

- Exception status flags output is incorrect for division, exception status flags output for the division is not the same as addition, subtraction, and multiplication, and doesn't follow IEEE754

For example, the overflow flag is not generated even if the division result generated is infinity (for MAX/MIN case).

- Rounding mode output is incorrect for fused operations, rounding mode for fused operations is not the same as addition, subtraction, and multiplication

For example, when rounding mode is RTZ (round to zero), the guard, round and sticky flags aren't ignored and the final output is changed by 1 bit.

- Getting output as X in fused operations if any of the operands is 0

For example, If any of the 3 operands are 0 in FMA, the result generated by the core is X.

These are the inputs I have given. All the following data is for 32-bit FPU, input1, input2, input3, output, and the expected output are represented in {1-bit sign, 8-bit exponent, 23-bit mantissa}, and status and expected status are represented as {Invalid, Divide by Zero, Overflow, Underflow, Inexact}

Division:

Input1 - 1_10000010_11011100000100010010000

Input2 - 1_00000001_11110010110000000000000

Out - 0_11111111_00000000000000000000000

Expected out - 0_11111110_11111111111111111111111

Status - 00100

Expected status - 00001

Rounding mode - RTZ (Round to Zero)

Operation - Division

The Input1 is being divided with Inp2 which is a very large number, the result should overflow and give infinity as the output, but as the rounding mode is RTZ (round to zero), the output should be the maximum possible number in a 32-bit floating-point number instead of infinity.

Input1 - 0_00000000_00000000000000000000000

Input2 - 1_11111111_00000000000000000000000

Out - 1_00000000_00000000000000000000000

Expected out - 1_00000000_00000000000000000000000

Status - 00100

Expected status - 00000

Rounding mode - RTZ (Round to Zero)

Operation - Division

0/Inf is giving overflow status even though the output is not infinity

Input1 - 0_01111110_11100000000000000000000

Input2 - 0_01111111_00000000000000000000001

Out - 0_01111110_01111111111111111111111

Expected out - 0_01111110_01111111111111111111110

Status - 00001

Expected status - 00001

Rounding mode - RDN (Round Down)

Operation - Division

The expected data is 0_01111110_01111111111111111111110 but getting output as 0_01111110_01111111111111111111111, both the inputs are positive and the rounding mode is round down, so the output shouldn't be changing because of the rounding mode

Fused Multiply Add:

Input1 - 0_00000000_00000000000000000000000

Input2 - 0_00000000_00000000000000000000000

Input3 - 0_00100100_00101010011010100100100

Out - x_xxxxxxxx_xxxxxxxxxxxxxxxxxxxxxxx

Expected out - 0_00100100_00101010011010100100100

Status - 000xx

Expected status - 00000

As input1 and input2 are 0, the output should be input3, but getting X from the core whenever any one of the inputs is 0 for fused operations.

Please let me know if these are the bugs in the core or the FPU, or if there's anything wrong with my understanding of floating-point operations.