Re: [libre-riscv-dev] div pipe

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

On Sunday, July 19, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:

> On Sun, Jul 19, 2020, 14:12 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
> wrote:
>
> > btw jacob i'm aware i did exactly the same thing to the ieee754 div
> pipe! i
> > did try running the div core unit tests, they weren't working.  i didn't
> > understand how to fix them so i proceeded anyway.
>
>
> DivPipeCore broke because you forgot (or didn't know) to account for the
> changing number of fractional bits when you changed the bit width for
> supported={UDivRem}


i was kinda aware of it but didn't know what to do.


>
> I was working on fixing that but gave up since I'm planning on using the
> FSM instead for the oct tapeout, and I'm planning on rewriting the div
> pipeline to add dynamic partitioning and loop-back for the 28nm tapeout, so
> the current div pipe core won't be needed.


about dynamic patitioning: i'd like to talk to whitequark about doing a
context manager that stores the partition mask...

*and provides m.If, m.Else and all other functionality* with literally zero
code changes.

the plan is that the mask-partition-manager would be initialised as:

     with pm.Mask(m, self.i.mask):

code then runs as:

             with m.If(some_partitioned_signal):

the Mask context *CHANGES* the behaviour of m.If, Else, Switch, Case and so
on.

underneath, the new context does all the work "on your behalf".

the actual number of changes should be *absolutely minimal*.  a single
indent to add the "with pm.Mask", the addition of the mask parameter to all
ispec and ospec (which should best come from ctx.op) and a few changes to
the constructor of each Stage.

we _might_ have to declare some parameters as explicitly PartitionedSignal,
plus some things which are single bit "test" (with m.If(foo)) these have to
be multi-bit, of width equal to the mask width.

aside from those changes there should be literally no changes to the actual
"logic" - the actual algorithm - at all

obviously, however, the fact that the data width can drop to 8 bit wide
means that running say 12 pipeline stages, the result will be produced far
earlier.

also any "constants" - assumptions that things will have the top bit set
for example - these need looking into.  i would *like* the Mask context to
even extend down into the behaviour of ArrayProxy so that even slices
(accessing psig[-1] for example) actually returns a special MaskArrayProxy
instead.

this would be fantastic, to be able to dynamically have the code reference
*different* parts of signals depending on how the Mask is set up.

however it would be seriously complex code.

the absolute last thing we need however jacob is a bunch of case statements
testing for different partition widths, all doing exactly the same thing.

one line of current code becomes ten, each almost identical excep different
widths.

that approach would be absolutely disastrous as the code repetition would
result in around a fivefold increase in code, and i can guarantee there
would be cut/paste errors.

in addition the explicit expansion of the code with such mask-based switch
statements would make it unmaintainable.


What we could do is just revert
> the bitwidth changes if we want to have working code anyway.


well, what i did was, if the configuration (initialisation) requests sqrt
or rsqrt the bitwidth is set to the 3x

no reversion should be needed.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev