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

[Luke Kenneth Casson Leighton]

On Fri, Jul 3, 2020 at 7:13 PM Staf Verhaegen <staf at fibraservi.eu> wrote:

> Indeed, coming from an ASIC background when I talk about IO I mean the
> IO pads indeed.

ok :)

> >
> > if however you are suggesting to use litex to create a bare verilog
> > *including* the peripheral HDL and full wishbone interconnect (but
> > stop at the FPGA side) this i believe is very sensible.
>
> Indeed that is what I am suggesting.

excellent

> > * you *might* be referring to IO as the "actual pads".  if that is the
> > case then yes, i agree this would also be sensible to not have litex
> > try to handle that: to have that done through nmigen.
> >
> > the only thing is, that's a *lot* of Signals so i think it would be a
> > good idea to have litex output a text, JSON or CSV file containing the
> > list of peripherals and their pinouts.
>
> Actually all the signals will be inputs and outputs from the top
> verilog.

yes... ah, as long as the naming is consistent then it would become
possible to determine (programmatically) what they are.

hmm what point have i missed... i think it's this: what i am saying
is: normally in the nmigen Instance you have to manually and
laboriously connect up the verilog signals to nmigen equivalent names.

this process, personally, i find not only extremely tedious, it is
also error-prone and is yet another file to edit, if a peripheral is
to be added (or changed).

example, TestModule:
https://gitlab.raptorengineering.com/tpearson/litex-boards/-/raw/wishbone_8bit_malfunction/litex_boards/targets/versa_ecp5.py

that declaration of Instance i would far rather be done as:

    instance = Instance("the_verilog_soc", **CSV_file_containing_signal_names)

and for the CSV_file_containing_signal_names to be a dictionary.  it's
one line of code to initialise that instance.

not 100 or 200 lines containing hand-typed function parameters which
are going to change as the code is developed.


> The platform class can also write it to a second file but this
> would be redundant information. You will actually define these signals
> in a platform file specific to the chip; e.g. starting from a file in
> https://github.com/enjoy-digital/litex/tree/master/litex/boards/platforms

ok that... looking at the versa_ecp5.py file...

("serial", 0,
Subsignal("rx", Pins("C11"), IOStandard("LVCMOS33")),
Subsignal("tx", Pins("A11"), IOStandard("LVCMOS33")),
),

yes!  that would do the trick!  that's a perfect format.  it contains:

* function name (uart, spi, sdram)
* function type (uart-tx, uart-rx, spi-mosi, spi-miso)
* ASIC IO name/number (C11, A11)

that's exactly the kind of format i would suggest.  interestingly,
it's also extremely close to how the pinmux.py program works (and what
OpenTitan JSON files look like).

if we have an ASIC platform file just like that, then as long as the
soc/integration/soc.py picks up the *same information*, using it to
create the signal names (io_uart_tx, io_uart_rx) which end up in the
verilog file, it is a trivial piece of code that spots the pattern,
reads the same ASIC platform file, creates an Instance from those
names, mapping the verilog names to their corresponding ASIC IO names.

l.