[libre-riscv-dev] microwatt IEE754FP

[Luke Kenneth Casson Leighton]

paul, hi,

thought i'd give a glimpse into the testing behind IEEE754

this is what jon dawson did:
https://github.com/dawsonjon/fpu/blob/master/adder/run_test.py

note that that test is expected to produce hundreds of thousands of test
vectors.

*this is perfectly normal* when testing IEEE754(!)

if you look at the test.cpp file it is a native operation that uses the c
library.  therefore running it on x86 will only be testing *against x86
IEEE754*, not POWER9!

compiled on *POWER9* it would obviously produce QNaNs etc etc for POWER9
compatibility.

this of course assumes you *have* access to native hardware.

our first exploration therefore took us via john hauser's excellent
softfloat-3 (with python bindings, sfpy):
https://github.com/ucb-bar/berkeley-softfloat-3

this allows full crossplatform emulation of the various different subtle
variations in IEEE754 FP rounding, NaNs and so on.

intel's NaN is different from ARM's NaN is different from RISCV blah blah
and so you simply must use an emulation library.


12 months later we had IEEE754 pipelines for the major operations,
including SQRT RSQRT and so on, and are looking to add sin, cos, log1p,
atan2 etc. next year.

our equivalent to jon dawson's unit tests we have libraries such as these:

https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/fpcommon/test/unit_test_double.py;h=6dee89d26fa98f821435848c9f92ec17cff2d9da;hb=dc9082559f7fba8555c2f76a6de95a6d84a6d087

there you can see it creates test vectors with zero, minus zero, inf, minus
inf and so on all making sure to get good coverage that would simply stand
no chance of being hit with pure random uniform distribution of values.

conversion from FP64 to FP32 or int etc had to be a little different
because again if you try to test the full range of FP64 converted to UINT16
almost all of those will be out of range (result in 0xffff in nearly 100%
of all uniformly random test cases).

one thing missing from the FP unit tests that i must add is exponentially
weighted random input for the non-normal numbers (less than 2^-126 for
FP32).

these are the values where the exponent is the absolute lowest possible
value and the mantissa then no longer has the implicit 1.  in this range it
is no good trying to use a uniform distribution of mantissas, you need an
*exponentially weighted* distribution of mantissas:

x = random(0, 23) # 23 is length of FP32 mantissa
mant_test = random((1<<(x-1))-1, (1<<x)-1)


basically what i am trying to say is that the effort for *testing* any
given IEEE754 FP implementation far exceeds the effort needed for the RTL
implementation itself by literally an order of magnitude, to do in any kind
of meaningful way that will give users confidence in the implementation.

about the only IEEE754 spec that could potentially be full coverage tested
is FP16 and even there that is 4 billion unit tests needed for 2-operand
tests (only 2^16 for 1 operand tests).  however POWER9 does not have FP16.

the primary reason why i mention this is because for proper OpenPOWER
Compliance such a comprehensive IEEE754 FP test suite is still *nowhere
near enough*, and the only sure-fire way to get 100% confidence is with a
Formal Correctness Proof.  and that is a *big* project.

remember the Intel Pentium FPDIV bug.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68