[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 #40 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jock Tanner from comment #39)
> I'm glad I managed to fix my Pycharm in terms of introspecting the Coriolis
> Python extensions. It was a stale skeleton cache. I deleted it manually (the
> usual “Invalidate and restart” did not do the trick), and everything
> suddenly started to work, including code completion.

exccellent.

> I made a wrapper function around 'Pin.create()', that tries to use some
> defaults for simpler use. I may got some of the defaults wrong though. Maybe
> more appropriate values can be deducted from the Hurricane's guts. Please
> have a look.

looks great to me.  the docstring quality is excellent.

i did my usual "make myself go over the code by making
whitespace cleanups" i find it's a good way to "review" by making my fingers
"do" if you know what i mean.  you'll need to do a git pull, there.

FIXED is a good default.  2.0 for the track-width, we might want to have
a class that sets that, at some point, rather than a function.

so the next two things, i think:

1. can you make a function which creates the BLOCKAGE "things"?
   then call it from add() and sub().  defaults to 2,3,4 however allow
   it to be parameterisable.

2. add() and sub() are near-duplicates and to some extent so is alu16.
   could you make a function which both add() and sub() call, and break
   out pieces for alu16()?  for example, the "find and place" add and sub

we want the actual "parameterisation" to be as basic and as bleedingly
obvious as possible by keeping it compact, with everything "coriolis-related"
behind functions which are well-commented as to what they do.

so for add() and sub() they should be calling functions that, effectively,
take nothing more than:

- the cell name
- the size
- the pins.

err... that's it!


the task after that is where the "real" stuff starts if you know what i mean.

you see how there's a massive amount of whitespace at the top of alu16.ap
and at the bottom? with tracks that, because of the VIAs, you can't fit
any multi-layer routing, so (apart from the very top 50 which is really
puzzling, must raise a bug with Jean-Paul about it) there's very little
opportunity to "optimise it".

however... this is entirely a problem of our own making, becaise both add()
and sub() have inputs at the *top* and outputs at the *bottom*.

what is needed instead is:

* inputs on add() and sub() to be *ALL* at the top (NORTH)
  - A+B to still be interleaved (just spaced closer together)
    and on the LEFT of NORTH
  - O to be in the RIGHT side of NORTH

* when "placed" inside alu16, the "add" cell needs to be *ROTATED*
  (not Orientation.ID), clockwise and
  "sub" needs to be rotated *anti*-clockwise

* alu16 A and B input and O output - just for fits and giggles - to be
  brought closer together (not as spaced-out across the whole of the cell)
  whilst still left on their respective sides.

* place-and-route attempted in the same way.

you _will_ find that the route of add() / sub() will go "quirky" i.e. if
certain combinations of the pins are given, the routing will not work
("error, pin is too far away from cell" that sort of thing)

you just have to experiment until you find a working combination.

this kind of thing is basically the "core" of what needs doing: looking at
how the router reacts, then going "hmmm" when it fails.


as we progress through to larger blocks, we will need to plan things
a bit carefully.

for example: there will be about *THIRTY* of these ALUs - some of them
extremely large - coming off of a *SINGLE* bus (!!).  i.e. the data
*in* comes *back* to the same location as the data *out*, back onto
the same bus.

therefore, when we get to that point, the "thinner" each ALU is, the
better.  in other words, we need a "chain" of pipeline stages, where
half of them go one direction, then the data "turns" round, and the
stages for the last half come *back* the other way.  that way we have
the inputs arriving back at the same place as the outputs, and ta-daa,
we can route them onto the same bus.

basically this here - alu16 - is a trial run of that concept, which will
be massively expanded by about 100 times larger than add() and sub() are,
right now.

(!!) :)


oh.

yes.

nearly forgot.

third task: we need to compute (auto-calculate) the size of alu16 based
on the relative size of add(), sub(), and the remaining components.
that one we might have to ask Jean-Paul about.

erm, why are we discussing this under this bugreport?  must create
a new one, really (doh).

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