[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 #37 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jean-Paul.Chaput from comment #36)
> Thanks for the hints.
> 
> Just to let you know, I'm working on the floorplan, so I'm studying closely
> the structure of the issuer netlist, as created after going through Yosys.

"show (modulename)" helps there.


> I've noticed something "unusual" (in my experience in hierarchical ASICs),
> some models have blocks and a few standard cells (relatively speaking).
> When processed, flat, this is not a problem, but if we want to place
> each block, then the top level, the placement of those stray cells
> may be difficult (meaning: far from optimal).

ta-daaa, nooow you know why i suggested the "group placement" idea :)

just like in the alu16 example, it contains:

* a add16 cell
* a sub16 cell
* some gates that mux add16 and sub16

i.e. not:

* a add16 cell
* a sub16 cell
* another cell containing the mux
* wires-only between those 3 cells.

it is basically pretty normal to do this, particularly for pipeline layouts.

for example we have:

* a combinatorial stage1 cell
* a combinatorial stage2 cell etc etc
* some gates that include registers bu t NOT in their own cell(s)

i.e. the source code was basically given a list of combinatorial blocks as
modules, told what the API is, and *in that parent* throws some register
latches together in a for-loop, dropping both the sub-modules and the registers
into its context.

in this way you regularly get very large blocks mixed in with "a few gates".

this is why i suggested the modification to allow a *list* of cells to be
placed in a Box.

and also as you see in alu16 i created that function which tracks down the
connections between cells by pattern matching on the *net* name rather than
have to name the cells explicitly.

changing the design to put everything into submodules, this would significantly
reduce code clarity.

however if it proves absolutely necessary it *MAY* be possible to automate
that, at the python level.

it would require a change to the entire codebase which is hundreds of modules
so would be a last resort.

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