[libre-riscv-dev] div/mod algorithm written in python
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Fri Jul 5 11:43:17 BST 2019
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)
> > 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.
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
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:
def setup(self, m, i):
divstages = 
if self.begin: # XXX check this
# HERE vvvvvvv
# 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*.
More information about the libre-riscv-dev