[libre-riscv-dev] 130nm for the hackers : finally a reality ?

Luke Kenneth Casson Leighton lkcl at lkcl.net
Fri Jul 3 13:55:21 BST 2020

On Fri, Jul 3, 2020 at 10:05 AM Staf Verhaegen <staf at fibraservi.eu> wrote:
> Luke Kenneth Casson Leighton schreef op do 02-07-2020 om 15:06 [+0100]:

> > i *believe* this has actually been done before, in particular for pulling
> > in verilog opencores peripherals, so it is not out of the ordinary.
> I think a better approach would be:
> - Get libre-riscv core as external in litex and combine it with
> peripherals.
> - Run full litex sweat, adapt flow to not do P&R and generate a top in
> verilog without any IO blocks.
> - Integrate this verilog top in nmigen with the IO and do place-and-
> route with coriolis from there.

of course - because if you start using litex for peripheral
management, then migen (litex) becomes a critical dependency for the

however: an adaptation (a mix of the two approaches) - i looked at
microwatt soc.vhdl last night:

the soc entity is defined from lines 49 to 235.  at line 87 you can
see a couple of UARTs, and below it an SPI master.  those are actual
peripheral pins that need to be connected to IO pads.

litex bypasses (does not include) soc.vhdl: core.py effectively
*replaces* soc.vhdl.

in *theory* then it would be possible to connect up the peripherals
directly and bypass parts of litex.  however looking at quite how much
litex actually does:

that's what would be need to be rewritten - replaced - with something
that links up all the peripherals (in nmigen). and that's a _lot_ of

therefore, annoying as it is (becoming a hard dependency), i am still
leaning towards using litex in the way it's intended, however perhaps
- for initial tests - creating something that only connects a UART
(nmigen-soc) and uses internal SRAM / ROM initially, and see how easy
/ hard it is to add peripherals.

basically do the microwatt soc.vhdl approach as a parallel, simple
exploratory test case.


More information about the libre-riscv-dev mailing list