[libre-riscv-dev] [Bug 154] Cell for Dependency Matrices is needed

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=154

--- Comment #17 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
hi staf, i realised after some thought that it is not so much DependencyMatrix
or DependencyRow that your recommendation critically  applies to, as it is the
current SRLatch being a multi-width object.

if *that* was returned to its original implementation (single bit inputs,
single bit outputs) then the valid concerns you raise would disappear, allow me
to explain.

to answer about the manual vs automatic placement: you need to see (and in
under one second you will immediately visually understand the following) the
gate-level diagrams from either "Design of a Computer" or from Mitch Alsup's
book chapters.

the wires between DM Cells (where the SRlatches are) *only* go dead straight,
horizontal, *or* they go vertical, *right* through the entire Matrix.  they
never do both, and they never curve.  ever.

in this regard they are extremely similar to how OpenRAM works, and
consequently i believe a similar programmatic layout approach may be deployed.

thus even if we did have to redesign the layout per geometry it is such a
trivial task (move some fully and exclusively straight and horizontal wires up
or down a bit) that even without having done this task yet i would be honestly
surprised if it was problematic or costly.

now, running the autorouter on DependencyCell (which i had to remove and agree
it should be reinstated sigh), *that* is a good idea, i feel, after working out
and setting suitable inputs and output locations best suited to the "straight
line" connections in the rows and columns.

btw you should be able to deduce what DependencyCell is, from its name :)

the only reason i went with the multi-bit  design of SRLatch was because i was
seeing literally seconds per simulated cycle and from an iterative design logic
perspective that was severely hampering my ability to make small fast
"debugging and understanding" changes.

now that i am happy with the overall logic as being reasonably correct in
maintaining instruction order, yes that optimisation, suited to nmigen's
limitations, can be undone.

i feel i will have to think how to make it possible to run both (and for there
to be a formal equivalence proof) because with the single bit SRLatch, even
with verilator and cocotb we may well be looking at seconds per simulated
cycle. will find out soon :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.