[libre-riscv-dev] introducing libre-soc: nmigen hybrid cpu-vpu-gpu

[Luke Kenneth Casson Leighton]

hi folks i just wanted to introduce our team, sponsored by NLNet: we
are developing a hybrid CPU-VPU-GPU in the nmigen HDL, and it is also
a dual-ISA processor: RV64GC in userspace, and Power ISA in userspace
and kernelspace.

if anton happens to be joined to this list i wanted to say thank you
for doing microwatt, as we have started a decoder by taking the ISA
tables in decode1.vhd and turning it into CSV files:
https://libre-riscv.org/openpower/isatables/

these tables we have then written a multi-level hierarchical decoder
that is *not* written (laboriously) in an HDL language: we use
*python* to read the csv files, and *python* to generate the recursive
hierarchy of HDL-based switch and case statements:
https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/decoder/power_decoder.py;h=446f6d38785cefaea16f5d89ca1cd95a46233df7;hb=2567453ceb0ca6551c24bf9a2064593f0c4ba7c6

the only reason we can do this is because we are not using a
dedicated-HDL-such-as-VHDL (or verilog), because, being trained as
software engineers (not hardware engineers), traditional HDLs we tend
to view as "machine code target languages" - not something to actually
be programmed in but something to be *output* by an NP-complete (and
well-used, popular) programming language.

it's a bit of a mind-bender, but well worth getting used to.

the upshot is: if anyone else wants a suite of CSV files containing
opcodes (in anton's excellent format!) they're there on the page:
https://libre-riscv.org/openpower/isatables/

also, i spent an entire day cut/pasting the instruction fields from
sections 1.6 and 1.7 of V2.07B (and then realised actually i needed
V3.0B *sigh*):
https://libre-riscv.org/openpower/isatables/fields/

so here again is a machine-readable table of the instruction fields,
and here's some source code which *reads* that machine-readable table:
https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/decoder/power_fields.py;h=0672e1eeaa37657e8165eddd2b600cd8335d771a;hb=2567453ceb0ca6551c24bf9a2064593f0c4ba7c6

i am a huge advocate of "not doing things the hard way".  for example,
anton: it would be a trivial exercise to adapt the power_decoder.py so
that it spewed out a text file which "happened to be in VHDL format",
which basically replicated exactly what decode1.vhd does, right now.
and, likewise, in chiselwatt you could do the same thing:
auto-generate Instructions.scala.

that would mean that any time you added a new instruction, you add it
*once*... to the *CSV* files... *NOT* "add it to the VHDL, then add it
to the chisel file, then someone else adds it to a verilog file" and
each time everyone wastes time, duplicates effort, and potentially
makes mistakes.

which reminds me: is the source code of the Power ISA Tech Ref Manuals
available, and would it happen to be in latex?  if so, it would be a
*lot* easier to write a program that parses the latex source code than
it would have been for me to manually cut/paste tables from an xpdf
view of the V2.07B and V3.0B PDFs.

this would have the added advantage that if the manuals are incorrect,
then the HDL code is absolutely guaranteed 100% to be incorrect
(because it exactly matches the error in the latex source of the
manual), and would require submitting a change to correct the
*manual*, thus ensuring that the manual was accurate.

for example i have found a number of formatting errors in the V2.07B
manual, which make it impossible to use without tedious time-consuming
corrections (V3.0B is better)

looking forward to hearing what everyone else is up to.

best,

l.