[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 #39 from Jean-Paul.Chaput at lip6.fr ---

> * 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.

Etesian is already capable of using ADD then SUB as big placed blocks
and then placing the remaining few cells around them, where we left
some free space, so inside a non-square area. That is, a square area,
minus the area of the already placed blocks. This is what is done in
an earlier layout experiment with doAlu16.

We may get away with it, *if* the stray cells are clearly a vector
and we can find back easily their matrix structure. But even then,
it has to be a very very regular structure or we will loose a big
amount of free space if the row or columns are "dented".
This is what you hinted in your signal naming scheme, I will see
what I can do.

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