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

bugzilla-daemon at libre-riscv.org bugzilla-daemon at libre-riscv.org
Fri Jun 28 06:09:28 BST 2019


--- 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
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,
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.

More information about the libre-riscv-dev mailing list