[Libre-soc-bugs] [Bug 199] Layout using coriolis2 main core, 180nm

[bugzilla-daemon at libre-soc.org]

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

--- Comment #38 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/alu_hier.py;h=59bca26e358051b9579a9686833c8a9c93a1e393;hb=8c398d8c100be10b21cc2c193b39a112cc331dc1#l188

example.

see those 4 submodules, add, sub, mul, shift? really clear, nice modular code,
right?

and further down, you can see ready/valid signalling to manage them, yes?

whilst the add, sub etc. end up as individual big cells, the ready/valid logic
is *in this module as well* and that is where the dozens of "unmanaged" cells
end up coming from which are not part if any "child" module.

to try to _create_ a submodule manually just to "contain" these, it is not a
goid idea.

firstly, it makes a mess of the code clarity.

secondly, some of those cells would be best placed in between say add and sub,
whilst others are best placed between shift and mul.  others, near *some*
inputs, others near *some* outputs.

or.. whatever.  you get the general idea.

one way to cheat is to simply put the child blocks in the parent in such a way
that these "floating" cells simply have very little choice about where else
they can be placed.  right against the left edge, for example, or make the
child the exact same width as the parent.

the ideal thing however, the "base" to work from, is to allow etesian.place to
taje a *list* of cells to be placed.

a second improvement would be to be able to specify a *list* of abutment boxes
to etesian place, which are unioned together to create a complex area beyond a
rectangle.

however the list of boxes can be (partly) done by calling etesian.place
multiple tines with different batches of cells.

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