hi, just so people know: obviously for a GPU and a modern CPU, an IEEE754 floating-point unit is essential. however, as you also know, verilog is an old language that would require macro-expansion of some form to modernise it with something approximating OO programming. for the libre riscv CPU/GPU we've chosen nmigen, instead, as it outputs verilog and still allows modern OO programming techniques to be used.

despite the fact that the IEEE754 FP unit is needed *for* the libre riscv CPU/GPU, it is important to note that the work is being done in a completely separate repo, to ensure that it is absolutely clear that this work is for *general* wider use.

we've started from jon dawson's excellent verilog IEEE754 FP code and have begun a process of conversion to nmigen, with a successful initial conversion of the adder, here: https://git.libre-riscv.org/?p=ieee754fpu.git;a=tree;f=src/add

the similarity between the various modules of jon dawson's code - not just 32-bit compared to 64-bit, also how the add is done vs multiply or divide - are striking, meaning that there is *significant* code duplication.

we will be removing *all* of the code-duplication with python OO programming techniques. base classes sharing the common functionality between all modules. class parameterisation so that FP16, FP32 and FP64 all share the exact same code.

in addition we'll be making sure that the code is properly documented (not excessively so), and, crucially, will be converting it to a pipeline architecture. to achieve this pipeline conversion process, a python class that, fascinatingly, originally came from a PyRTL example, has been adapted for use with nmigen.

the current design - jon's original work - is a state machine with variable completion time. it's quite compact in that there are no single-cycle variable-length shifts used: instead, a single 1-bit shift is deployed with a variable-clock-cycle detection on when to end shifting.

obviously that cannot be preserved for a pipeline architecture, however it would be particularly interesting to try to preserve both designs within the same codebase.

if anyone would like to assist with this work you are most welcome: please do join the libre-riscv-dev mailing list http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev otherwise i am happy to answer questions on either of these lists.

l.