admin管理员组文章数量:1024664
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.
Share Improve this question edited Nov 20, 2024 at 12:04 Muhammad Sufyan Ahmed asked Nov 19, 2024 at 8:43 Muhammad Sufyan AhmedMuhammad Sufyan Ahmed 92 bronze badges 2 |1 Answer
Reset to default 0You 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
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.
Share Improve this question edited Nov 20, 2024 at 12:04 Muhammad Sufyan Ahmed asked Nov 19, 2024 at 8:43 Muhammad Sufyan AhmedMuhammad Sufyan Ahmed 92 bronze badges 2-
3
I can't help you with the RTL, but for what it's worth,
0xC1E0000000000000is 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", although0x41E0000000000000= +2147483648 would be, as would0xc1e0000000200000= -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
Reset to default 0You 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
本文标签：
版权声明：本文标题：floating point - Why does my RISC-V FCVT.W.D RTL implementation return 0x00000000 for input 0xC1E0000000000000 instead of 0x8000 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://it.en369.cn/questions/1745573474a2156878.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
0xC1E0000000000000is 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", although0x41E0000000000000= +2147483648 would be, as would0xc1e0000000200000= -2147483649. (The "int_result" of 0x00000000 is clearly very wrong.) – Steve Summit Commented Nov 19, 2024 at 10:30