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

[Luke Kenneth Casson Leighton]

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

>
> Hello Staf,
>
> Please find in attachement a "settings.py" to put into the ".coriolis/"
> directory of your bench.
>
> Just a few words of explanations about how the P&R work. The algorithm
> of the detailed router is more sensitive to the density of the design
> than the sheer size of it. In that regard, the RISC-V is (obviously)
> a RISC architecture which is less dense than a 6502 one of CISC kind,
> even if smaller. By density, I mean the interconnexion graph which is
> the netlist. The RISC graph is more sparse. So a smaller but denser
> design can be more difficult than a bigger but sparser one (I made
> some measurement about that).


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?


>
> Now, to tune the router, you may adjust three parameters in the
> "settings.py" configuration file:
>
>   katana.hTrackReservedLocal
>   katana.vTrackReservedLocal
>
> You want to increase one or both by step of one. It makes the global
> routing more and more difficult, but reserved free space inside cluttered
> GCells. You may increase the H reservation more than the V one
> (this is due to our standard cell design). Of course be attentive that
> the global router still complete. If too much tracks are kept for local
> use it will not be able to finish.
>
>   etesian.spaceMargin
>
> To increase the free space in the design. This may not be as effective
> as it should because Coloquite nonetheless tend to make tight clusters.
> In your case, you see that whatever space you put, a big cluster remain.
>
> I've some ideas to circumvent that problem and allow more compact designs.
>
> In any way, the P&R still need some improvement, I will work on it.
>
>
> Best regards,
>
>
> On Fri, 2019-05-24 at 20:02 +0200, Staf Verhaegen wrote:
> > Goodday,
> >
> > I am trying to get Arlet's MOS6502 implemented with Coriolis. I am using
> the
> > alliance-check-toolkit flow. I did add a bench on my gitlab mirror of the
> > repo.
> > In the Arlet6502 branch I added the verilog code as a bench and provided
> the
> > cmos45 directory to test it with nsxlib standard cell library. This was
> > created based on the VexRiscv bench. Although the latter can complete for
> > Arlet6502 it does not. Log output of the run can be found in cmos45.log.
> > In order to see if the hierarchy in the design is a problem in branch
> > Arlet6502_flat I adapted the yosys synthesis script to flatten the
> design.
> > This does not solve the problem and log of failed run is attached as
> > cmos45_flat.log.
> >
> > As the core is smaller than the VexRiscv one, I did not expect problems
> here.
> > Feel free to add this bench to upstream alliance-check-toolkit.
> Flattening
> > the design as I do in my patch gives yosys more optimization opportunity
> so
> > this may also be added to the flow; maybe as an option.
> >
> > greets,
> > Staf.
> >
> --
>
>       .-.     J e a n - P a u l   C h a p u t  /  Administrateur Systeme
>       /v\     Jean-Paul.Chaput at lip6.fr
>     /(___)\   work: (33) 01.44.27.53.99
>      ^^ ^^    cell:      06.66.25.35.55   home: 09.65.29.83.38
>
>     U P M C   Universite Pierre & Marie Curie
>     L I P 6   Laboratoire d'Informatique de Paris VI
>     S o C     System On Chip
>


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68