[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 #40 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jean-Paul.Chaput from comment #39)
> > * 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".
> 
> I understand very well your need for the clearer possible code.
> I think it should not be needed that you isolate the few additional gates
> in a special (and artificial) block.
> 
> My concern is that, if we take the ADD/SUB, the blocks will be
> dwarfing the stray cells, and we get very sub-optimal placement.

this is why the place-by-list.  if there is huge space, and the number
of stray cells relatively small, the priority is to get them roughly
in the right place, not to get them super-efficiently packed.

setting 10% or even 50% extra etesian space on something that contains
only 50 stray cells, when the alternative is that they are placed miles
away from the (large) sub-cells, this is way better, even though the
Etesian place was never originally designed for such tiny placement.

> We may get away with it, *if* the stray cells are clearly a vector
> and we can find back easily their matrix structure. 

ah.  right.  so this was where i began exploring an alternative to matrix
design, in alu16.py

written in python, i created a recursive "net-analyser" subroutine.

its parameters give a starting *net* - not a cell pattern-match - a *net*
pattern-match list - and it will loop on the following:

* find all cells connected to the net-pattern.
* find all nets connected to those cells
* if there are no new nets, stop.
* otherwise:
   A) add the cells found to the "accumulated result"
   B) continue recursively searching with the NEWLY FOUND nets
      to find MORE cells

it is a Graph walking algorithm, basically, identifying related cells given
net names.

in this way you *do not* need to know *anything* about the names of the
cells that are connected *to* the nets.  they can change any time, and
you just don't care, we can continue developing the HDL and *not* worry about
having to throw away massive amounts of coriolis2 hand-crafted layout code
(because there isn't any).

what you care about is "what cells are connected to o[15]" and the
function will give you that answer.

*this* allows to pick up the "stray cells" because you obviously know the
Inputs/Output NET names of the sub-block (ADD16, SUB16), and can run a for-loop
on them, calling this function and accumulating everything associated with
them.

what we do not want to then have to do is to do manual placement on those stray
cell groups, having identified them all (or appropriate subsets), we just need
to be able to do a small "rough" placement / grouping, in an area that will be
mostly routing wires, in between one of the sub-blocks and another sub-block,
or between any given sub-block and the I/O of the parent.

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