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

[Luke Kenneth Casson Leighton]

On Thursday, July 2, 2020, Staf Verhaegen <staf at fibraservi.eu> wrote:

> Luke Kenneth Casson Leighton schreef op do 02-07-2020 om 13:27 [+0100]:
> > On Thu, Jul 2, 2020 at 12:04 PM Staf Verhaegen <staf at fibraservi.eu>
> wrote:
> > > Is there already a design with mixed litex and nmigen code ?If so, it
> would save me from reinventing the wheel for the Retro-uC.
> >
> > i've been looking for one: what i've found so far is this:
> https://git.m-labs.hk/M-Labs/HeavyX/src/branch/master/
> examples/simplesoc_ecp5.py
> >
> > litex however is migen (legacy), and my feeling is that to get it
> toproperly work you need to "back down" to a common denominator, whichis
> convert everything to verilog (or ilang) and, if doing simulations,run
> verilator (or now cxxrtl).
>
> Well aware of that, therefor my question.


just making sure we are on the same page.


>
> > in other words i believe in order to use litex you kinda have to
> treatnmigen as a foreign architecture (vhdl, verilog) just like it's
> donewith any other soc such as microwatt, vexrisc and so on.
>
> I would like to go to other way: having litex peripherals as external
> source in nmigen top. Reason is that I do plan to use the nmigen Platform
> for defining the IOs etc; also for the 0.18um prototype.


yes i would very much like to do this as well, improving the pinouts.py
pinmux program to be able to output nmigen (the opentitan team copied the
idea from me but did not consult anyone outside of their own focus.
consequently it is fantastic well documented work... using systemverilog
and only suitable for RISCV).

the pinouts pinmux system autogenerates the entire IO substructure based on
a simple specification: number of UARTS, to be connected to pins A2/3 etc

if the only thing that litex did was to be a "migen library" you could
always import a foreign instance: compile litex to verilog, then import
that as a nmigen Instance.

however litex is not just a migen library.

the problem is that litex core.py classes assume the existence of...
something (some core) plus litex is not just a migen program, it contains a
whole stack of other code including compiling firmware, downloading
compilers and much more.

in other words in order to save time not duplicating all of that work
involving the compilers, firmware etc, the following strategy might work:

* define the IOs in mnigen and add them as "foreign instance"
peripherals... to litex

* create a core.py again as a foreign instance (in nmigen)

* when creating a soc.py pull in the foreign IOs and link them to the core.

i *believe* this has actually been done before, in particular for pulling
in verilog opencores peripherals, so it is not out of the ordinary.

l.



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