[libre-riscv-dev] [Bug 126] Make Div core conditional (enable signal)

[bugzilla-daemon at libre-riscv.org]

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

--- Comment #8 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #7)
> (In reply to Luke Kenneth Casson Leighton from comment #5)
.
> > 
> > The moment that the combinatorial blocks are given access to o_valid (etc)
> > that's it, it's game over, they can never be combinatorially chained
> > together with StageChain, not without a total code rewrite.
> 
> ok. yeah, having o_valid just go through the pipeline blocks would be better.

It means moving stuff to reduce gate latency is reeeal easy.

> > The first pipeline stage is what needs bypassing, dropping the INT data
> > directly into the DIV pipe.
> 
> I would move both FPDivStage0Mod and DivPipeSetupStage into the same stage
> as denormalization. 

Hm, hm, the subnormal alignment (making sure the MSB is 1) is a
count-leading-zeros plus a single clock multishifter. It's quite a high gate
latency.

> that pipeline stage would handle sign flipping for
> signed integers as a parallel combinatorial unit.

That's another possible approach, not discussed before: combinatorial stages
that (similar to how muxid works) generate decision-routing output that results
in data going to *completely different* blocks.

> I would also move DivPipeFinalStage and FPDivStage2Mod into the same stage
> as normalization, that pipeline stage would handle sign flipping and special
> cases (overflow and div-by-zero) for integers.

Separate block, routed based on ctx.operator.

> this allows all the interior stages to be only DivPipeCoreCalculate stages,
> since those are the ones with the big propagation times.

With INT pipes (FP32/64) on radix 16, that's divisible.

On radix 8 (3 bits at a time) neither INT nor FP will divide evenly, leaving
room to put pre and post processing with no fate latency penalties.

Much as I would like all this to be automated, I don't think it can be. We just
have to patiently go through and plan the interconnect.

With INT, FP, SIMD, Cancellation and sharing of the
alignment/pre/post-normalisation *and* doing multiple operations (ADD, MUL,
DIV) it's going to be a handful :)

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