I am debugging a discrepancy between the RTL implementation of the RISC-V FCVT.W.D(double precision to signed-int conversion under IEEE 754 format) instruction and its behavior in the reference model (Spike). Specifically, for the double-precision floating-point input 0xC1E0000000000000 (subnormal, negative, with a tiny magnitude), the model returns 0x80000000, while the RTL outputs 0x00000000. Observations:

• Model Behavior: The reference model (Spike) follows IEEE 754 and correctly converts this value to the saturated integer result 0x80000000 as it would be, because it's a corner case but not the overflow condition(as per this reference IEEE 754).
• RTL Behavior: The RTL generates two results internally: int_result: Produces 0x00000000, which is selected as the final output. special_int_result: Produces 0x80000000, but this result is not chosen due to backend logic. Here is the chunk of code that enables the special result selection in RTL

assign int_result_is_special = info_q.is_nan | info_q.is_inf |
                               of_before_round | ~info_q.is_boxed |
                               (input_sign_q & op_mod_q2 & ~rounded_int_res_zero);

Goals: I am looking for:

Insights into aligning RTL behavior with the model. Clarifications on how IEEE 754 standards handle such cases. Suggestions for improving the RTL logic to handle this and similar edge cases correctly.

I am debugging a discrepancy between the RTL implementation of the RISC-V FCVT.W.D(double precision to signed-int conversion under IEEE 754 format) instruction and its behavior in the reference model (Spike). Specifically, for the double-precision floating-point input 0xC1E0000000000000 (subnormal, negative, with a tiny magnitude), the model returns 0x80000000, while the RTL outputs 0x00000000. Observations:

• Model Behavior: The reference model (Spike) follows IEEE 754 and correctly converts this value to the saturated integer result 0x80000000 as it would be, because it's a corner case but not the overflow condition(as per this reference IEEE 754).
• RTL Behavior: The RTL generates two results internally: int_result: Produces 0x00000000, which is selected as the final output. special_int_result: Produces 0x80000000, but this result is not chosen due to backend logic. Here is the chunk of code that enables the special result selection in RTL

assign int_result_is_special = info_q.is_nan | info_q.is_inf |
                               of_before_round | ~info_q.is_boxed |
                               (input_sign_q & op_mod_q2 & ~rounded_int_res_zero);

Goals: I am looking for:

Insights into aligning RTL behavior with the model. Clarifications on how IEEE 754 standards handle such cases. Suggestions for improving the RTL logic to handle this and similar edge cases correctly.

• floating-point
• system-verilog
• ieee-754
• register-transfer-level
• riscv32

• 3 I can't help you with the RTL, but for what it's worth, 0xC1E0000000000000 is not "subnormal, with a tiny magnitude". It's equivalent to -1 × 2³¹ = -2147483648.0. As a floating-point number, it's normal, although converted to a 32-bit signed integer, it's the minimum value, so it's certainly an edge case, but I don't think it should be a special case. I would not call it "saturated" or an "overflow case", although 0x41E0000000000000 = +2147483648 would be, as would 0xc1e0000000200000 = -2147483649. (The "int_result" of 0x00000000 is clearly very wrong.) – Steve Summit Commented Nov 19, 2024 at 10:30
• Yes, you are absolutely correct, I have updated my question actually model(spike) is not treating this case special anyhow(that means no NV or OF flags will be set). But, the issue is why RTL treated this operand c1e0000000000000 as an special case from the very start? I guess rtl is not properly behaving specifically for this minimum edge value (as the max value is working fine). – Muhammad Sufyan Ahmed Commented Nov 20, 2024 at 10:19

1 Answer 1

You can use float-toy to visualise the float value, which is not a subnormal.

0xC1E0000000000000 is simply equals to -2147483648 or 80000000 on a saturated integer so spike is correct.

So in that case the float is just the maximal value representable in the sint if you consider that 0x8000_0000 is not 0 (i.e. you are saturated). You can use this tool to visualize it.

You may find a way to modify your data path to generate the proper value because there is way to avoid the dp to give you 0 but this also depends of how you are executing the fp to int conversion. Otherwise you can just mux the final value depending of the presence of a special value