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

[Jacob Lifshay]

On Wed, Jul 3, 2019 at 1:02 AM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>
> btw, jacob, there's a trade-off here, of python-code readability and
> hardware-understandability.
>
> <snip>
>
> the SIMD-splittable MUL code far exceeds that limit, comprising some
> 250 to 400 "boxes" that take something like one minute of 100% CPU
> time to render.
Yeah, it could be split up more. I wrote it based on getting it to
match a known-working multiply implementation (the non-nmigen one).
Once it is known to produce the correct results in all cases that I
bothered to test, I know that any potentially unconnnected signals
don't actually matter, since they are all just writing values that are
not used (otherwise it would fail the tests).
>
> that is not all: the consequences of the "unreadability" of larger
> modules go well beyond compromising understandability, they will also
> adversely impact the time it takes to create a layout.
>
> if you look at the scoreboard dependency matrix code, it is very very
> specifically subdivided into modules-of-modules.  the matrices are 2D,
> however one module deals with 1 dimension, and *ANOTHER* module
> creates an array of THOSE modules, to create the 2D.  ANOTHER module
> joins the results (output) of each 1D array using OR (or NAND),
> creating a 1-bit output that is then Cat'ed together to produce the
> overall output from the DM.
>
> *this is really important*.
Understood.

> so please: use graphviz to view the resultant code *every time you
> save a file*, and if you can't read it, or the rendering of the
> graphviz takes an unacceptably long time, take that as an absolute top
> priority sign that the code *must* be split into separate nmigen
> modules.
Will do (if not every time, at least every non-trivial commit).