[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 #5 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #3)
> (In reply to Luke Kenneth Casson Leighton from comment #2)

Arg I just managed to delete sonething I wrote and can't get it back. It was to
do with how StageChain has no knowledge of or access to the Data *Handling*
side.

This is thoroughly deliberate: it is precisely this which allows combinatorial
blocks to be chained either with StageChain *or* as Pipeline blocks, and for
the very same combinatorial blocks to NEVER have to worry about which or how
they are used.

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.

> note that for the div pipe, since the first compute stage is in the same
> pipeline stage as the actual numbers are input, early-in would not be needed
> for integers or fp.

Except that the specialcases need to be bypassed, as does the "denorm" stage
(which deals with subnormals). See diagram here
http://git.libre-riscv.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/fpdiv/pipeline.py;h=499bd79c4373ce7ecfe2ada31f12fd39c58f4830;hb=refs/heads/master

The first pipeline stage is what needs bypassing, dropping the INT data
directly into the DIV pipe.

> > It means adding an external "stall" capability, in effect.  6600 pipelines
> > *never* stall. Saving power however is a good reason to break that rule.
> 
> just think of it as stages that don't have valid data have X for the data
> lines, the X is just selected to be the previous value that was in the
> flip-flops since that saves power.

Yehyeh. Good perspective.

> > 
> > What happens in fpmul and fpadd, they check out_do_z.  Zeros get propagated
> > down the chain. Nothing changes.
> 
> if you want divcore to output zeros for zero inputs, just swap the values in
> DivPipeCoreOperation so SqrtRem is numbered 0. this works since sqrt(0) ==
> 0. div doesn't do that since it solves for the largest q that satisfies
> dividend >= divisor * q, when divisor is 0, obviously the largest q is all
> 1s.

Okaay. That would work.

> this will also have the benefit of finding cases where we are still using
> magic numbers instead of the named values, since those places will break.

Shouldn't be any.

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