[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon at libre-riscv.org]

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

--- Comment #68 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jean-Paul.Chaput from comment #67)
> (In reply to Luke Kenneth Casson Leighton from comment #65)
> > btw remember, jeanpaul, we aim to break the layout into blocks (cells)
> > hierarchically, anyway, so that if necessary we can reuse some (particularly
> > the large FPU ALU blocks) and also do a little more control over routing, as
> > well as add in GND VIA rings around blocks.
> > 
> > so, learning how to do blocks early would be good.
> 
> No problem. You should have a look to the RingOscillator bench in
> alliance-check-toolkit. Fully manually placed & routed block.
> Shows all the technique you can use.

okaaay. is there a way to visualise that?  i notice "make view" is missing?

> For FPU block, the P&R should be used unless you have a clear idea
> of the placement. But from what I know, it is not trivial.

the blocks are just a long chain.  combinatorial block, registers,
combinatorial block, registers, repeat, repeat.

the direction from each block is forward-only.  in other words, inputs
come in exclusively on left, outputs go out exclusively on right.

so what i don't want to see happening is a massive mess of several
hundreds of thousand gates.

instead what i would like to see is a defined "width" parameter, set for
all "blocks", then the connections between each are defined such that
the inputs from one block come "straight" from the outputs of the previous.

this i think is very similar to the RingOscillator, which is in effect
a type of pipeline.

> Then with a script, wrap up the whole in a ring of VIAs.

ok.

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