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

[lkcl]

On Sun, May 26, 2019 at 11:34 AM Jean-Paul Chaput
<Jean-Paul.Chaput at lip6.fr> wrote:
>
>
> Hello Luke,

hi jean-paul, as always, thanks for replying.

> On Sat, 2019-05-25 at 21:28 +0100, Luke Kenneth Casson Leighton wrote:
> > This is fascinating insight that I am cc sharing with libre-riscv-dev.
> >
> > What advice would you give to anyone designing a RISCV processor, right now,
> > that was intended to be laid out with alliance/coriolois2?
> >
> > For example, I am going to a lot of effort to modularise the implementation
> > into very deep hierarchical structures, to avoid exactly the kinds of complex
> > graphs that you say may be problematic, even if it makes software simulation
> > drastically slower.
> >
> > Does this sound reasonable?
>
> In fact, this is a very difficult question to respond to. There are lots of
> trade-off involved and I think there is no definitive answer. I can give you
> some elements of reflexions anyway.

 appreciated

> Making deep hierarchical structures, is mostly for the human designer so it
> can better manage and debug the architecture. It's a way of modularizing for
> better block abstraction. But, if you just give the top level netlist to
> Coriolis (or any commercial tool for that matter), it will be processed flat.

 understood.

 the context is that this chip is going to be so massive (8mm^2 if
done in 45nm) that i am concerned that a flat automated layout will
(A) overwhelm any high-end machine it's run on (B) produce a layout
that contains "ringing" effects (power drop-outs), and (C) suffer from
cross-talk

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.

 it's also quad-core, with an additional low-power boot and IO
"management" core, and the target frequency is 800mhz.   it's a bit of
a monster - nothing like it in the libre world has ever been
considered, before.

> Historically, the reason to the "block" approach was that the tools,
> synthesis and P&R where not powerful enough to manage a whole chip, so it
> has to be broken into manageable units.

 i am relieved to hear it, because this design is so massive that
breaking down into progressively smaller blocks is going to be
absolutely essential.  buying a machine with 256 GB RAM (or greater)
is not something i'd like to have be a build dependency.

 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.

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

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

(4) can *buses* be made, by the P&R, to turn by 45 degrees (or an
approximation of a curve)?

many many thanks,

l.