[libre-riscv-dev] [Bug 217] create a "ring" system which allows pad locations to be specified conveniently

[bugzilla-daemon at libre-riscv.org]

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

--- Comment #52 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jock Tanner from comment #50)
> Sorry for another big delay on my part.

no problem.  we still need to get the MoU signed.  money's allocated,
just not accessible yet.

> 
> (In reply to Luke Kenneth Casson Leighton from comment #45)
> > so could you track down that auto-box-size computing function and then
> > look at removing all hard-coded parameters?
> 
> 'Module.compute_ab()' added.

great.

> > you'll likely need to run add.build() manually, then sub.build() manually,
> 
> I kinda anticipated such changes in workflow, so I divided the submodules
> processing into 'build()' and 'place()' phases beforehand. Now I added an
> utilities such as 'Module.submodules' iterator and
> 'Module.find_submodule(name)'.

excellent

> > *then* in ALU16()'s build constructor it will have access to the
> > (computed) width+height of each,
> 
> Also not a problem: after 'build_submodules()' it can be accessed via
> submodule's 'ab' property.
> 
> > *then* it can compute its width and
> > height.
> 
> Here I stumbled on how to get the end result.
> 
> > ALU16 computes its height based on:
> > max(Add.H, Sub.H, middle-stuff-H) + 100 (to give room for the routing)
> > 
> > and its width based on:
> > Add.W + Sub.W + middle-stuff-W + 20-or-so
> 
> I tried this approach, but middle stuff size calculates as 650×650 and
> everything bloats. And there are many “unplaced design” errors. =(

yes.

ok, you'll see i've done a lot of experimentation, i went back to using
an iterative try-it-and-see approach

hum

also i did this:

* changed the I/O pins for ALU16 so that they are closer to the middle

* put all the pins for add and sub at the top (this needed experimentation
  just to get an I/O config for each that would "pass" routing)

* made add's pins a *mirror* of sub's pins (you'll see why, next)

* *ROTATED* add and sub so that their inputs/outputs "faced" each other

* put in a hard-coded positioning for the "middle" placement (ALU16
  little stuff)

* called place *only* (for all the little stuff)

* after the place, *only* call route *not* place-and-route

what happens if you call place-and-route after place, the entire box is
filled with "dummy cells" that go *underneath* (overlap) the add() and
sub() boxes.

whoops

this only showed up because of the rotation of add() and sub().

the reason for doing the rotate (and mirror) is to get the add() and sub()
I/O to try to "connect" with dead-straight lines, right across the
middle-stuff.

however this (if you think about it carefully) creates an artificial barrier 
where no VIAs can be properly placed.

whoops.

ah.

just found what might be a serious bug: two routes trying to occupy the
same space.

jean-paul, i will raise a bugreport on gitlap.lip6.fr

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