[libre-riscv-dev] [Bug 132] SIMD-like nmigen signal for partitioning

[bugzilla-daemon at libre-riscv.org]

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

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

> whoever didn't actually write it. the multiplier is designed so that it acts
> like a simple pipeline where every input comes out exactly N stages later,
> where N is configured by the instantiating code.

If the code is not doing single cycle results we cannot use it.

The pipeline API is based on combinatorial stages, where the "register" part is
handled in the data-opaque fashion.

This implies in turn that, just like div_core, parameterisation is needed where
the mul code can be told, "please give me a combinatorial object that will deal
with stage 0 of multiplication, which *I* will wrap with registers, NOT you".

And, "please now give me another combinatorial object, which will deal with
stage 1. *I* will take responsibility for connecting the stage 0 to stage 1".

The div_core has a function which tells the caller of the API exactly how many
"stages" are needed.  What was it...

http://git.libre-riscv.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/div_rem_sqrt_rsqrt/core.py;h=cef62a343ad8da05d6c8746a30d8a276a050660f;hb=refs/heads/master#l49

DivPipeCoreConfig.n_stages.

That was it.

This is the architecture that we need. A MulPipeCoreConfig object, a n_stages
function, the registers removed from the multiplier code, such that the
Pipeline API can the explicitly construct combinatorial building blocks and
join them together, just as was done with FPDIV.

Otherwise, yes, it gets into a hell of a mess.

With the multipath pipeline re-routing code I am writing (trying to write,
sigh) it will be possible to construct rerouters that divert 64 bit MUL
requests down a separate N-stage pipe, that comes *back* to the main pipe
later, where 8/16/32 goes straight down a 1-clock path.

Having that kind of complex logic *inside* the multiplier is A pointless B a
duplication of the pipeline API C something else I don't know what :)

Oh, yes: confusing, as it is a sync block, where every other ALU module is comb
based (and the Pipeline API takes care of sync/registers).

Having the multiplier do multi stage is also going to be hell, because whilst
the data goes in and comes out a few cycles later, the *control* information
(ctx, etc) does not... 

Ah, now I see why you suggested a separate control pipe.

Yuck :)

Don't like it, at all.  Not because it wouldn't work, but because it is the
only code that would need to do it.

And it is unnecessary.

If the multiplier code has an API that is very similar to that of div_core, the
problem is solved.

Can you do that?

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