[libre-riscv-dev] [Bug 154] Cell for Dependency Matrices is needed

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=154

--- Comment #16 from Staf Verhaegen <staf at fibraservi.eu> ---
(In reply to Luke Kenneth Casson Leighton from comment #11)
> (In reply to Staf Verhaegen from comment #8)
> 
> if i can summarise: DependencyRow is gone, and merged into DependencyMatrix?
> 
> assuming yes: my concern with that was for P&R - we will not be doing full
> automatic P&R in coriolis2 - was to do isolated *small* blocks (cells) that
> *may* be done automated (or manual), and are small enough to visually
> inspect without being completely overwhelmed by the sight of the resulting
> GDS image (or intermediate output before that)
> 
> a 2 dimensional matrix is not only extremely unlikely for the autorouter to
> get right, it is much more complex to design the manual layout.

If your autorouter is not able to that, I don't think you will ever be able to
make a design working in a more recent technology node at a decent speed. For
these nodes meeting timing will need buffer insertion for optimal timing
performance, if you will need to do that manually in your custom matrix layout
this will need to be optimized for each node, maybe even every design. You
should be able to rely on a tool to do this properly.

> 
> (as you will no doubt know, i mention this for the benefit of other readers,
> staf, coriolis2 layouts are *python* programs!)
> 
> so the justification for doing 1D of 1D objects was so that the person doing
> the DependencyRow can write a python P&R coriolis2 program that just puts
> SRLatch objects down in a simple 1D for-loop...
> 
> ... and the person doing the DependencyMatrix can likewise write a python
> coriolis2 program that does the same for DependencyRow.
> 
> that was the plan.  does it make sense? i described it to JP and, although
> he hasn't reviewed the actual code as you did, he liked the idea.
> 
> hm i should ask him if he could take a quick look.
> 
> could i ask, could you perhaps explain the reasoning behind the
> recommendation to flatten the structure? what would be the advantages of
> doing so?

It's the same discussion of old time of assembly coding versus higher level
language. What you are actually doing is the equivalent of inline assembly for
the dependency matrix because you think you can do the work better than the
compiler. Personally I would rather work on optimizing the compiler than
overriding the compiler with own inline assembly.

To be more concrete, the placer currently tries to minimize the length of the
interconnects. By doing the SRLatch array manually you say that you know better
than the placer what the good placement of the cells is. When scaling to
smaller nodes, the placer has to be changed to do placement for optimizing
timing and do proper buffer insertion. At that point I think it would be
difficult to do that better manually. As said above when scaling to smaller
nodes you will need to insert buffers on longer signals etc. meaning that you
may need to do that also manually.

But I leave it up to you and JP to decide how to do it, I will include a SR
latch. But it will mean that you do the Dependency Matrix not in nmigen + yosys
because the tools will try to optimize your design and fiddle with the design
you wrote in nmigen.
I think for getting this to work you will need to use Instance for all cells in
the design you want to place manually in coriolis script otherwise nmigen and
yosys will fiddle with your design.

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