[libre-riscv-dev] [Bug 217] create a "ring" system which allows pad locations to be specified conveniently

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=217

--- Comment #74 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jean-Paul.Chaput from comment #73)
> (In reply to Luke Kenneth Casson Leighton from comment #72)
> > ok i managed to:
> > 
> > * crush doAluFlat.py down to 465x800
> > 
> > * crush doAlu.py down to 520x840
> > 
> > visually you can see that there is plenty of room for improvement,
> > it is quite fascinating to examine.
> 
> Yes. What would be very informative is to try with increasing size
> of blocks (16, 32, 64, 128 bits) to see if the "flat" advantage
> persists.

fascinating. doAlu16.py - worked immediately (after i worked out that
you have to expand the space down the middle to accommodate the extra
tracks, duh)

took about.... 40 seconds to make the code changes: 600.0 width worked
perfectly (good guess, because, later, trying 590 failed).

doAlu16Flat.py - couldn't find a width that would work, not after trying
about 8 times to expand the width.  600 failed.  700 failed with
a missing config (https://gitlab.lip6.fr/vlsi-eda/coriolis/-/issues/11)
800 failed.  900 failed.

> I'm pretty sure we can further compress with an optimized manual
> routing of the inter-block (especially by using M2+M4 correct
> balance for vertical routing)

honestly i think this experiment has worked really well.  the only ways
i would think it worthwhile to expand is in the identification of the
blocks involved in each bit (the muxes).

we do actually need that for another part of the project, because, similarly,
i have some SR Latches which are specified just like the MUXes.

this is a standard recursive graph-walk algorithm, from edges to nodes
to find more (unique, not-previously-seen) edges:

1. here are the starting inputs/outputs
2. what cells are connected to them
3. add their inputs and outputs to a NEW list to recursively search
4. make sure that in the NEW list, the OLD list is excluded from the search
5. repeat from step 2. with the new list

a loop on that algorithm with first [a0, b0, o0] then [a1, b1, o1] etc.
will identify each "group" of cells.

then, it would be good to have a way to specify that only each *group*
should be Etesian-placed, within a manually-created abutment box.

whilst it is by no means perfect (each place a0b0o0, a1b1o1... a15b15o15
could theoretically be in different locations), to identify the cells
algorithmically from the inputs/outputs is much better than to hard-code
what yosys/ABC produces.

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