[libre-riscv-dev] TLB

[Luke Kenneth Casson Leighton]

On Mon, Apr 22, 2019 at 6:28 PM Jacob Lifshay <programmerjake at gmail.com> wrote:

> > the only thing to watch out for is *not* to use the python variable
> > multiple times.  the pythonvariable contains nmigen *code fragments*,
> > consequently using it more than once will result in DUPLICATION of the
> > gates it represents.
> >
> Duplication is perfectly fine because yosys's default synthesis script,
> synth, runs opt, which includes opt_merge, which is a deduplication pass,
> as well as abc, which has a lot of fancy logic optimizations.

 true... however on examining the output (pre-optimisations), the
sheer volume of duplication has in the majority of cases made the
graphviz so large and unwieldy that, as a "sanity and understanding"
tool, using the "show" option of yosys has been rendered utterly
useless.

 running any of the optimisation passes to remove that duplication is
also useless, as the process creates an order or two magnitude *more*
detailed graphs, removing the names of signals in the process, and it
becomes impossible to do any kind of meaningful debugging and
comparisons for a totally different reason (no signal names).

 with the duplication being so insane, and in some cases containing
unnecessary state-based combinations that *may not actually be
detectable* by an optimising phase, i do not feel that "trust the
optimiser" is a safe decision.

 examples include, particularly in FSMs, to set up a connection (the
output of some other module to be conditionally routed for example),
where in fact, actually, that output could be connected *all the time*
as it is the *input* that is driven by the FSM, and, furthermore,
there is a flag that the "user" of the FSM detects to check that the
output is valid, anyway.

 such examples *cannot* be safely optimised, as they would
fundamentally change the output - to one where the output actually
doesn't matter, but the optimiser *does not know that* and *can* not
know that.

 examining the graphviz output as part of the development process
(after each and every flle-save) has allowed me to catch several of
this type of opportunity.


 another key (indirect) driving reason behind examining the graphs is
from experience with auto-router algorithms in CAD/PCD software:
they're rubbish.

 several years ago, when being completely dismayed at how bad libre
software is at PCB layout auto-routing, after initially being
delighted to get hold of a "professional" CAD package with an
autorouter, i was absolutely horrified at the mess that it made.

i have since learned that manual placement with "routing assist"
(called "push and shove") is far more effective at producing a decent
layout.

 so that strategy, along-side a nested programmatically-driven
approach, is what is leading me towards recommending alliance2 /
coriolis for handling the layout (alliance / coriolis2 layouts are
actually python applications).

 knowing that the graphviz output of any given module is reasonably
small (or regular), writing a python program to auto-generate its
layout (or make the decision to do the layout manually, or whether to
deploy the auto-router) will be a manageable task.

by being familiar *in advance* with the netlists, that task will be easier.

so... it's... yeah, it's several layers.  yes, the optimiser will
catch some things: no it won't catch them all, and that's enough to
cause me to not "implicity trust it in all cases", and use manual
visual inspection.

l.