minimax VS picorv32

On FPGAs, a register file probably fits better into distributed RAM than block RAM.

On Xilinx, for example: a 64-bit register file doesn't map efficiently to Xilinx's RAMB36 primitives. You'd need 2 RAMB36 primitives to provide a 64-bit wide memory with 1 write port and 2 read ports, each addressed separately. Only 6% (32 of 512) entries in each RAMB36 are ever addressable. It's this inefficient because ports, not memory cells, are the contented resource and BRAMs geometries aren't that elastic.

A 64-bit register file in distributed RAM, conversely, is a something like an array of DPRAM32 primitives (see, for example, UG474). Each register would still be stored multiple times to provide additional ports, but depending on the fabric, there's less (or no) unaddressed storage cells.

The Minimax RISC-V CPU (https://github.com/gsmecher/minimax; advertisement warning: my project) is what you get if you chase efficient mapping of FPGA memory primitives (both register-file and RAM) to a logical conclusion. Whether this is actually worth hyper-optimizing really depends on the application. Usually, it's not.

I haven't used it on a huge design (I'm usually a VHDL person), but it was a hassle-free replacement for iverilog when regression testing Minimax. Performance is substantially better; compilation times are worse.

Note that you can't compare LUT4 results (ZPU @ 440 LUTs) against LUT6 results (PicoRV32 @ 750 LUTs). The ZPU is remarkably small, and it's a bigger gap than a direct comparison shows.

SERV is a fair comparison, since it's architected for 4LUTs and I suspect the synthesis results come from iCE40 tools.

I have a contender in the "very small" space, too [1], although I don't claim it's as mature or complete as SERV. (If Minimax was excluded from your post on the basis of insanity, I'm OK with that.)

[1] https://github.com/gsmecher/minimax

I develop Minimax (https://github.com/gsmecher/minimax), an open-source RISC-V implementation. It's currently written in both VHDL and Verilog (the two implementations are equivalent, though I am likely to drop the VHDL implementation if it's too much work to keep them both.)

The best point-of-entry for "tiny" MCUs these days is FemtoRV32-Quark or SERV. I also maintain my own small RISC-V core (Minimax), though it's early on in graduating from "experiment" to "real design".

The Pico RV32 is pretty small, and can go as low as about 750 LUTs, with most features elided. I don't know how Xilinix LUTs translate to Lattice though.

Picorv32: https://github.com/YosysHQ/picorv32

There are loads of free RISC-V cores that you can read the source of and run on cheap FPGAs. Take a look at PicoRV32: https://github.com/YosysHQ/picorv32

picorv32 is written in Verilog.

In short: it works, though the implementation lacks the crystal clarity of FemtoRV32 and PicoRV32. The core is larger than SERV but has higher IPC and (very arguably) a more conventional implementation. The compressed instruction set is easier to expand into regular RV32I instructions than it is to execute directly.

That is, reducing the number of LUT required to implement a CPU of a given ISA.

A basic RV32 CPU is down to 500-700 LUT.

    https://github.com/YosysHQ/picorv32

Have you looked at PicoRV32? https://github.com/YosysHQ/picorv32

What I mean is that you use the FPGA fabric to implement a soft-core CPU, like MicroBlaze (Xilinx) or Nios II (Altera/Intel) or RISC-V or any other CPU you like. Then you can do the MP3 or WAV signal decoding in software, which will be orders of magnitude easier to do than to do it in hardware. For a media player, this is more than adequate.

My definition of a RISC CPU is one that has a reduced instruction set. In other words, the category of CPU is defined by the size of the instruction set, not in how it is implemented. Consider for example RISC-V CPUs. These are defined by their open instruction set alone, in spite of the fact that many implementations of RISC-V CPUs exist: some pipelined, and some not.