[libre-riscv-dev] [Bug 99] IEEE754 *pipelined* FPDIV unit needed

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=99

--- Comment #9 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #7)

> There comes a certain point where the additional readability from the
> reduction in lines of code is entirely negated by the lack of comprehensible
> names.

yehh i took shortcuts, and having five 80x65 xterms to jam as much information
on-screen as possible is an absolute necessity for a multi-class modular
hierarchy: far more important than name length.  long names results in
extension of functions beyond reasonable limits because arguments end up
having to span multiple lines.  that in turn often pushes a function well
beyond
what can fit (*vertically*) onto a single page, requiring multiple page-up
page-down page-up page-down page-up page-down actions in *multiple windows*
in order to work out what the hell's calling what calling what.

plus, the original code from jon dawson was so short that it was pretty
obvious.  
a, b, z.  a is operand1, b is operand2, z is clearly the result.

functions (actually, properties) in FPBase definitely got named fully
after their purpose.

so, z is often actually a module (an Elaboratable), which then has properties
"is_zero", "is_nan" and so on.

basically, i'm aware there's a lot of clean-up and code-morphing that still
needs to be done.  the challenge was in keeping the unit tests running at
all times, as debugging is, to be frank, hell.  introducing even a single
error is a bitch to track down: there's one now which was detected from
FP16 MUL.


oh, btw, FP16 DIV is actually a higher priority for dev / debugging purposes
than FP32.  the reason is that the code-coverage from random result generation
hits corner-cases far more often.

the rounding error introduced last week into FPMUL would have been flat-out
statistically impossible to encounter on FP32 because there was no way that
random result generation would have created the case.

in fact there is no reason why, with FP16, we should not consider doing
a full (complete) coverage of 0x0000-0xffff for both src1 and src2,
particularly on FPGAs or when converted to iverilog.

-- 
You are receiving this mail because:
You are on the CC list for the bug.