[libre-riscv-dev] [Alliance-users] Coriolis flow fails on Arlet verilog MOS6502 core

[lkcl]

On Sunday, May 26, 2019, Jean-Paul Chaput <Jean-Paul.Chaput at lip6.fr> wrote:

>  "ringing" effects (power drop-outs), and (C) suffer from
> > cross-talk
>
>   (C) More difficult. In the long run I would want to integrate this
>       feature, but I cannot say when.


It would be nice, there is no great immediate hurry, we are still at the
early HDL stage.

I will likely end up creating something in python that creates VIA borders
with room for entry and exit wires around blocks.


>
> > i have experience in PCB layout that i would like to deploy, to help
> > ensure that these potential issues don't occur.
> >
> > > If you want to prevent that, you can P&R each block then P&R the
> blocks.
> > > It will require you to create a true floorplan. This can be done with
> > > Coriolis,
> > > but manually (through Python scripts).
> >
> >  i am _very_ happy to hear that.
> >
> > > In that case you have to perform a
> > > careful analysis of the communications (number of wires, busses)
> between
> > > the blocks. If you have no multiplier, you can even envision to
> manually
> > > place cells in a data-path fashion.
> >
> >  we've SIMD multipliers (partitionable) with a vector processing
> > front-end, predication, L1/L2 caches, SMP, IEEE754 FP units down to
> > the 16-bit level, and it's a multi-issue Out-of-Order engine based
> > around an augmented variant of the CDC 6600.
>
>   So try to P&R a block flat to see if it can be done. If not, start
>   break it into sub-unit. The cache however must be kept separated as
>   it is a higly regular block (manual placement).


There is a surprising amount of this design that can be done as regular
repeated blocks.

A 6600 uses 2D dependency Matrices that are SR Latches wired up
horizontally and vertically, to create horizontal and vertical regularly
spaced rntry and exit ports, ORing rows and columns together.

Likewise the ALUs are (rather large) repeated blocks (8x 32bit FPADDs *per
core* for example), as this is a 3D VPU / GPU / CPU.

Also the register file is enormous: 256 64 bit regs, subdivided into BYTE
level write-enable lines, and striped 4 ways on 32 bit boundaries.  And due
to the Dependency Matrices already generating the RE/WE unary lines,
there's no binary address decoder. It really is just a 2D bunch of
regularly repeated cells.

So you can perhaps see why it is reasonable to consider a hierarchical part
automated part manual layout.

Letting the autorouter handle say the 2D Matrices as flat blocks, it will
certainly just make a mess.



> Question here is
>   how do you implement them ? Usually foundry supply memory blocks.
>   Maybe have a look at OpenRAM.


Good reminder.


>
>   More generally, you will have to select a Design Kit to make your
>   chip. Get access to that may be very difficult (only (big) companies
>   or academics can have it).


Staf may be able to be our firebreak, there. Hi Staf :)


>
> >  i'd also like to take the opportunity to do a form of "EM Shielding"
> > - lines of VIAs around each block - that you see on R.F. designs.
> > 800mhz is starting to get to the point where cross-talk is a concern.
>
>   I'm familiar with it, because of the analog & mixed signal extension
>   of Coriolis (present in the git but not advertised yet as it is not
>   finished).


Nice. Will look forward to seeing that.


>
> >  can i ask a couple of specific questions:
> >
> > (1) is there a way, in python, to route a "bank" (Bus) of wires, from
> > one location to another, keeping them together in parallel?
>
> > (2) is the same available with a kind-of... "partial auto-route"?  by
> > that i mean, if i have a series of blocks, and i want a Bus to be
> > semi-auto-routed around say the *top* of the blocks, is it possible to
> > guide the auto-router in some fashion (for example by specifying a set
> > of rectangles that it is - or is not - permitted in)?
>
>   Same answer for (1) and (2), the router accepts that some nets are
>   already routed. If you make the routing (with Python script) before
>   running the router, it will keep your wires. But you have to do
>   a complete routing.
>     I think I did allow to specify only global routing at some point
>   but I'm not sure it still working.


Appreciated.  At least, the routing on a block can be done, independent of
other blocks and also independent of when that block is used, right?

Hmmm.... I have a horrible idea... :) To create the "holes" that might be
needed, to do partial manual and partial autorouting in an arbitrary
sequence, add fake blocks that cause the autorouter to avoid some sections,
and even end early with a "fail", incomplete, then remove the fake block
and carry on with manual routing :)

    You may see an interesting example on how to do routing by scripts
>   in the RingOscillator benchmark of alliance-check-toolkit.


Thanks.


>
> > (3) can the P&R make tracks that turn by 45 degrees (or in an
> > approximation of curves), or do they need to turn through the use of
> > VIAs, changing direction only on a new layer?
>
>   45 degrees wire are not managed/allowed in automatic digital routing,
>   they are too complex to manage by an algorithm (as far as I know it
>   is also true for commercial tools).


Mentor PADs does fine, you can even specify if it is allowed or not. Mind
you, PADS layout is just absolutely superb. Intuitive, obvious, and
extremely comprehensive.  ORCAD is atrocious by comparison.


>     So only 90 degrees angles. Usually you need to put a VIA and change
>   layer to respect the preferred routing direction.


Ok. That should be fine, I have seen this done effectively. Also, for
Buses, it is sometimes a good idea, rather than try bending all the tracks,
change layers, deploy VIAs on the diagonal, then do it again: if done on a
strict regular grid the Bus track lengths are not changed.


>
>  But for short dog-legs
>   (one track), no VIA will be used, the dog-leg will be all in the same
>   layer. This another feature I need to improve.
>
> > (4) can *buses* be made, by the P&R, to turn by 45 degrees (or an
> > approximation of a curve)?
>
>   Technology allows it. You may do it by hand (script).


>
Great.  That's fine. It would be good to have as an option, just in case
VIAs start to get in the way.


> But router do not
>   use them. Mostly used in analog design (RF parts).


To keep noise down due to RF signals trying to not go in straight lines,
yeah.  EM waves have a strange habit of wanting to do that :)


> > many many thanks,
>
>   You're welcome.
>
> > l.
>
> PS: At our lab in Sorbonne Universite / LIP6 / CIAN, we are also in the
>     process of building a very very small RiSC-V. We want to use it as
>     a demonstrator for Alliance/Coriolis but our approach is to use
>     old tech and ramp up to newer one progressively while adding the
>     missing features to Coriolis. Our first goal is to make a small chip
>     in AMS 350nm by the end of 2019 (or beginning of 2020).


That would be superb to track, and follow up with a monster chip afterwards.

This is the one you are planning to test FreePDK45 on, ultinately? Because
if so, it would make sense for us to do a 45/40nm if you have already
proven that a small design will work.

L.