[Libre-silicon-devel] IEEE754 FPU in nmigen

[Luke Kenneth Casson Leighton]

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.