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

[Samuel Falvo II]

I'm not sure this will be of any help or use, but the original KCP53000
processor uses an instruction decoder which is almost built using the same
PLA-style decoder that the 6502 uses (absolutely no pipelining at all).
I've had no problems with ArachnePNR successfully elaborating a design for
the iCE40HX8K FPGA.

On Sat, May 25, 2019 at 1:28 PM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> 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
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>


-- 
Samuel A. Falvo II