-
Notifications
You must be signed in to change notification settings - Fork 665
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] In new FPU, division by NAN incorrectly sets NX and DZ fflags #1192
Comments
Hello. I have a question. It seems that the values of Moreover, if the value of I look forward to your response. Thanks! |
Hi @fly-1011 thank you for your comment! It's been more than 1 year so I don't remember details unfortunately. Can you observe a mismatch between CVA6 and Spike on this snippet in the first place? This will let us know if the reporting issue is in the description or in the snippet. EDIT:
|
Hi @fly-1011 , |
Hello,Thank you very much for your response! I have confirmed that the value of fflags in CVA is 0x18.
|
Ok! I updated the issue accordingly, thank you for your comment. |
Hi @flaviens ,
According to the IEEE 754 standard regarding NaN, the exponent bits of ft0 and ft1 are not all ones, which does not meet the criteria for NaN. In the spike debugger, using fregs prints a NaN value because ft0 is a double-precision floating point number, while fregs is intended for single precision.
In cva6, single-precision instructions processing double-precision floating-point numbers will only handle the lower 32 bits. For more details, see: openhwgroup/cvfpu#118 (comment). The lower 32 bits of both ft0 and ft1 are zeros, which should indicate a zero divided by zero case. Note: #1071 seems to be a similar situation,so I think it's not a bug. |
Hard to say, it's been a while I haven't touched floating-point numbers. But then why do Spike and the other designs like Rocket not raise the same flags in this situation? Is there some permittivity in the RISC-V spec? |
Based on my understanding, when double-precision floating-point numbers ft0 and ft1 are processed by single-precision instructions, they can either be treated as NaN or only the lower 32 bits can be considered. It appears that Spike treats them as NaN, whereas cva6 uses the lower 32 bits.
|
According to the RISC-V unprivileged spec "NaN Boxing of Narrower Values":
After a quick look at this I understand that ft0 and ft1 should be treated as 32-bit NaNs. |
Thank you very much for your patient reply!👍 |
Is there an existing CVA6 bug for this?
Bug Description
I create a new issue, similar to #1071, but this affects the new FPU and changed the fflags signature.
I discovered that with the new FPU, Ariane unexpectedly sets the NV (invalid operation) and the DZ flags when we call
fdiv.s
on floating-point operands that have the 32 lower bits as zeros but are NaNs.Example snippet to reproduce:
From spike, fflags should be clear, but Ariane sets fflags=0x18, which corresponds to NV | DZ.
Let me know if I can help debug that.
Thanks!
Flavien
The text was updated successfully, but these errors were encountered: