You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've detected a bug in CVA6, probably in CVFPU but I'm not certain. I initially posted the issue in the CVA6 repo before moving it here. I used the commit 17743bc7120f1eb24974e5d7eb7f519ef53c4bdc of CVA6.
Brief bug description
A conversion of nan from simple to double may set a lot of bits in the mantissa, unexpectedly, under specific microarchitectural conditions.
Example instance 1
In this instance, we convert the single-precision 0xffffffffff800000 using fcvt.d.s.
We expect to get 0xfff0000000000000 as a result, but under the circumstances induced in the very simple ELF, we get 0xffefffffffffffff. I confirmed the expected result with spike, and in the snippet further below in CVA6.
Here you can observe that the value dumped is erroneous.
Example instance 2
In this instance, we convert the single-precision 0xffffffff7f800000 using fcvt.d.s.
We expect to get 0x7ff0000000000000 as a result, but under the circumstances induced in the very simple ELF, we get 0x7fefffffffffffff. I confirmed the expected result with spike, and in the snippet further below in CVA6.
Interestingly, performing the conversion out of context works, for example this snippet executes apparently correctly. It is similar if we replace the values with the values of the second instance.
Hi there!
I've detected a bug in CVA6, probably in CVFPU but I'm not certain. I initially posted the issue in the CVA6 repo before moving it here. I used the commit 17743bc7120f1eb24974e5d7eb7f519ef53c4bdc of CVA6.
Brief bug description
A conversion of nan from simple to double may set a lot of bits in the mantissa, unexpectedly, under specific microarchitectural conditions.
Example instance 1
In this instance, we convert the single-precision
0xffffffffff800000
usingfcvt.d.s
.We expect to get
0xfff0000000000000
as a result, but under the circumstances induced in the very simple ELF, we get0xffefffffffffffff
. I confirmed the expected result with spike, and in the snippet further below in CVA6.Here is the ELF and waveforms of the bug.
A symptom of the bug is the first write to address
0x18
, which essentially writes the result of the conversion.Here you can observe that the value dumped is erroneous.
Example instance 2
In this instance, we convert the single-precision
0xffffffff7f800000
usingfcvt.d.s
.We expect to get
0x7ff0000000000000
as a result, but under the circumstances induced in the very simple ELF, we get0x7fefffffffffffff
. I confirmed the expected result with spike, and in the snippet further below in CVA6.Here is the ELF and waveforms of the bug.
A symptom of the bug is the sixth write to address
0x18
, which essentially writes the result of the conversion.Example instance that runs correctly
Interestingly, performing the conversion out of context works, for example this snippet executes apparently correctly. It is similar if we replace the values with the values of the second instance.
Therefore I deduce that this is conditioned by some microarchitectural effects (maybe branch prediction but I am not certain).
Thanks!
Flavien
The text was updated successfully, but these errors were encountered: