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

bugzilla-daemon at libre-riscv.org bugzilla-daemon at libre-riscv.org
Mon Jan 13 18:24:01 GMT 2020


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

--- Comment #11 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Staf Verhaegen from comment #8)
> (Sorry accidently commit previous comment. Redo comment)
> 
> After reading a little further I think that the architecture was developed
> at a moment where not the current synthesis, place-and-route and timing
> check tools were available. 

yes. i need to get back to Taiwan and update everything. so much has happened
even in 8 months.

> With current tools I think it is better to
> implement it all on the DependencyMatrix level without sublevels. Incomplete
> and non-checked code but I hope to get the idea across:

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.

(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?

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


More information about the libre-riscv-dev mailing list