[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 11:14 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Fri, Jul 5, 2019 at 3:01 AM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
> >
> > ________________________________
> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> > On Fri, Jul 5, 2019 at 10:51 AM Jacob Lifshay programmerjake at gmail.com wrote:
> > >
> >
> > On Fri, Jul 5, 2019 at 2:46 AM Luke Kenneth Casson Leighton
> > lkcl at lkcl.net wrote:
> > >
> >
> > On Friday, July 5, 2019, Jacob Lifshay programmerjake at gmail.com wrote:
> > >
> >
> > I'm not sure how setup and
> > process are supposed to be defined,
> >
> > there's lots or examples and they're documented in nmutil/iocontrol.py
> > setup can be ignored entirely for non-module-based combinatorial stages.
> >
> > done. this should work:
> >
> Your patch appears to have been Obliterated by GMail (TM)

 niiice :)

> > with module-based designs, setup takes the module that submodules must be
> > added to,
> > Seems like a bad design,
> >
> > it's topologically directly equivalent to the code that you advocated,
> > passing in "m" (the module) in order to access m.d.comb.
> >
> > since the calling code should be able to pick
> > the submodule names, not the called code. What happens if a module
> > needs to make 2 instances of the same class as different submodules?
> >
> > design the pipeline so that it doesn't, is the simplest answer, there.
> > the parent modules are themselves added into other modules. the chances
> > of a clash are minimal.
> Well, I wanted to use module-based classes to implement the div pipeline:

that's already done.

class FPDIVBasePipe:

    def elaborate(self, platform):
        m = ControlBase.elaborate(self, platform)
        m.submodules.scnorm = self.pipestart
        for i, p in enumerate(self.pipechain):
            setattr(m.submodules, "pipediv%d" % i, p)
        m.submodules.normpack = self.pipeend
        m.d.comb += self._eqs
        return m

the only things that you need to do are the *combinatorial* blocks
(conforming to the Stage API).

(1) write a converter from FPSCData format to DivPipeCoreInputData format.

  this to go into div0.py.  div0.py is also where
DivPipeCoreSetupStage belongs.  as long as its input format is in
FPSCData it can *replace* FPDivStage0Mod.

 if on the other hand you want to keep them separate, an *extra*
module will be needed, converting from FPSCData format into
DivPipeCoreInputData format, and it would be added in divstages.py:

class FPDivStages:
    def setup(self, m, i):
        divstages = []
        if self.begin: # XXX check this
            divstages.append(FPDivStage0Mod(self.width, self.pspec))
            # HERE vvvvvvv
            divstages.append(DivPipeCoreSetupStage(something))
            # HERE ^^^^^^^^

(2) write a converter from DivPipeCoreIntermediateData to
FPAddStage1Data format (don't worry about the name)

 this to go into div2.py

(3) write an intermediary-to-intermediary combinatorial module

this to go into div1.py

to reiterate: you *do not* need to write the "pipeline constructor"
code, because it is *already done*.

l.