[libre-riscv-dev] [Bug 44] IEEE754 FPU inverse-sqrt

[bugzilla-daemon at libre-riscv.org]

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

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

> I was planning on creating an arithmetic pipeline similar to the multiplier
> in that operations just travel in a simple manner from start to finish and
> we can add on all the pipeline control circuitry externally (since we still
> haven't fully resolved how pipeline control will work).

 it turns out that scoreboard-style designs don't need stallable pipelines.
 i'd like to keep using the same FP code style (same class structure, same
 base classes) so that any code-morphing can be done to *all* FP* units.

> > also keep the integer and FP pipelines *separate* for now: the FPU code
> > is seriously complicated already, and in actual usage, int would hold up FP
> > and FP would hold up int.
> Actually, the fpdiv uses an integer div+mod internally, so having separate
> fp and integer pipelines here actually makes it more complicated. The only
> int operation supported is div+mod.

 i mean: creating a pipeline-stage bypass system where either
 INT or FP data can be put into the same unit, and the INT version
 skips the de/-normalisation, that's doable.

 creating an infrastructure that *shares* the integer pipeline stages:
 that's way more complex.

 however *for now*, please don't do either of those things: the FP code
 is complex enough as it is.  see below.

> Since the algorithms are relatively simple, I'm expecting the fixed-point
> core to be done in 1-2 days and then the FP
> unpacking/normalization/special-case-handling can be added on the front and
> back.

that's a good strategy.  you saw the ep08_15.pdf thesis i found, which
contains OTFC radix-2/4/8 INT-DIV?

can you also, for now, create _separate_ fixed-point pipeline classes,
(each stage separated out into its own class), put them together to create
a fixed-point div/mod, with unit tests, then move on to use the *same*
classes within the FP code.

you'll find that there already exist unpacking, normalisation and
de-normalisation
classes, and pipelines that can be used.  the only major missing class that
needs writing is the "FP DIV special cases code" - i can do that, based on
Jon Dawson's FPU state-machine.

also, please don't put the classes in the simple-barrel-processor repository,
put
them in the FPU repository where they belong.  or, we create a separate
"INT ALU" repository or they go directly in the soc repository.

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