[libre-riscv-dev] div/mod algorithm written in python

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Fri, Jul 5, 2019 at 12:12 PM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Fri, Jul 5, 2019 at 3:59 AM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
> >
> > i've added the z-bypass signals (out_do_z, oz) and also the context
> > (FPPipeContext) - all commented-out - as they need to be initialised
> > correctly.
> >
> > these have to go into absolutely every data spec because they're
> > passed (untouched) right the way through the pipeline.  bit annoying,
> > but hey.
> I had wanted to create new data spec and stage classes that add the
> out_do_z, oz, muxid and route it around the DivPipeCore classes,
> thereby keeping the algorithms more understandable since they don't
> have a bunch of extraneous variables.

 the trade-off being: "yet more classes".  if that's a balance you can
live with, so can i.  bear in mind that out_do_z absolutely has to be
used by what you [plan] call DivPipeCore, because it disables
processing.

 also, when cancellation is added, that will affect DivPipeCore as
well.  so bear that in mind, that there may not actually be much point
in having the (planned) separation.

> That's why I named them
> DivPipeCore instead of DivPipe. The DivPipeCore classes would be
> submodules of the DivPipe classes.

 remember that every submodule added slows down simulations.  i had to
drastically alter the design of the scoreboard code because of this.


> > * the muxid *must* be unmodified.  it's the Reservation Station identifier.
> >
> > * out_do_z and z are set in SpecialCases.  they must not be touched by
> > any "processing", as they already contain a result
> >
> > * ctx.op is where you can completely change the functionality of the
> > pipeline: it's the ALU "operator", from the instruction decode phase
> > (or is funct7, or... whatever).
> That will be translated into DivPipeCoreOperation values (using
> create_signal to create the signal, since it adds in the decoder
> param, giving nicer debug output values). I'm not using ctx.op
> directly, since there are several div variants that all translate to
> UDivRem.

 it would be better if that was done locally, i.e. the public API is
self.ctx.op and the private *in-module* usage of self.ctx.op is done
even without having a public self.operator (at all), i.e. there's a
*local* variable "operator" within each DIV module, used like this:

    size = len(self.ctx.op) # actually, from pspec, self.pspec['op_wid']
    operator = DivPipeCoreOperation.create_signal(size) # whatever
    m.d.comb += operator.eq(self.ctx.op)

as i wrote in a cross-over message, the spec for that operator *HAS*
to propagate *RIGHT* the way up to the ReservationStations.

this is because it's a *public* (general) API, where self.ctx.op will
change the SIMD behaviour, be used for MUL, ADD, FCVT and much, much
more.

now, we _can_ look at propagating a class, all the way from the setup
of FPipeContext, right the way down to the individual pipeline stages
(make it a member of self.ctx)...

... but not right now.


> The DivPipe (non-core) classes will need to handle translating signed
> integer division into unsigned division + negations +
> overflow/div-by-zero handling.

... ok so if DivPipeCoreOperation is more complex than just a single
signal, you can use Cat() or something, on DivPipeCoreOperation (see
nmutil.nmoperator "cat()" function), to squash it down and jam it into
self.ctx.op.

or, we can look (right now) at making the default "class" for
FPipeContext be a "Signal", and the setup for the fpdiv (back in
test_fpdiv_pipe.py) passes in a DivPipeCoreOperation class name into
FPipeContext.

.... you get where i'm going with that?  DivPipeCoreOperation is an
API specific to DIV, and it needs to fit into the *general* API
(ReservationStation).

l.