[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 #45 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jock Tanner from comment #44)
> Sorry for being missing for some time, it was a busy week for me. My other
> projects and local bureaucracy required my attention.
> 
> So I reworked the ALU16 example with the hope that this approach could be
> (re)used in a future work.
> 
> https://git.libre-riscv.org/?p=soclayout.git;a=blob;f=experiments7/utils.py

niiiice.  that's really clean.  excellent - and precisely what i was hoping
to see.


oh.  one really important thing: we need an "auto" option for the width
and height... and for the *hierarchy to be able to work with that*.

so for example:

Add and Sub use the standard "auto-box" height/width (i forget the function,
sorry)

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

this is actually really important because if we set fixed W+H and the HDL
changes, we're screwed when it comes to re-running the layout.

also, there *may* be small changes when we go to different geometries,
so it's really important to stay flexible and not have hard-coded sizes.

> The amount of required parameters can also be reduced. Maybe we could teach
> the module to deduct either its size or pin spacing. Now the initialization
> looks quite fuzzy.

yes, there's a function which does auto-size assessment, however it does
width *and* height, it doesn't do "width given height" or "height given
width".

also, we need "estimated size of the *remaining Cells which have not been
laid out*.

or "estimated size of just the following group of Cells".

we might have to do that by splitting the HDL into further modules
(this is a fallback plan).

so for example, everything in ALU16 that connects Add() and Sub() -
*all* that HDL goes into a *separate* module, such that ALU16()
*only* has 3 sub-modules:

* Add
* Sub
* ConnectAddAndSub

and thus *only* needs "routing".

however this would be a bit of a pain and i'd like to avoid redesigning
the HDL to this kind of extreme level, if possible.


> I deleted all the 'print' statements from the example, since I could not
> grasp the logic and requirements behind them. Perhaps it makes sense to
> return some logging, preferably with a proper use of 'logging' facility.

good idea.  if you can put a template / example together i'll tend to use it :)

so could you track down that auto-box-size computing function and then
look at removing all hard-coded parameters?

you'll likely need to run add.build() manually, then sub.build() manually,
*then* in ALU16()'s build constructor it will have access to the
(computed) width+height of each, *then* it can compute its width and
height.

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