minimax

It is better to say RVC is almost never present without the full-size 4 byte instructions since we have one counter example: https://github.com/gsmecher/minimax This is an experimental rather than practical design that only directly implements the compressed instructions in hardware and then implements the normal RV32I instructions in "microcode" written using the compressed instructions.

> Right now, most devices on the market do not support the C extension This is not true and easily verifiable. The C extension is defacto required, the only cores that don't support it are special purpose soft cores. C extension in the smallest IP available core https://github.com/olofk/serv?tab=readme-ov-file Supports M and C extensions https://github.com/YosysHQ/picorv32 Another sized optimized core with C extension support https://github.com/lowrisc/ibex C extension in the 10 cent microcontroller https://www.wch-ic.com/products/CH32V003.html This one should get your goat, it implements as much as it can using only compressed instructions https://github.com/gsmecher/minimax

The first ARM was microcoded.[1] The DEC Alpha used microcode (nee PALcode) for a number of functions. There are RISC-V implementations using microcode.[2] Not all CICS chips use microcode. Indeed, you can make an argument the 6502 and Z80 don't have microcode rather a ROM sequencer. Depends on how fine you want to grind your axe. [1] https://www.righto.com/2016/02/reverse-engineering-arm1-proc... [2] https://github.com/gsmecher/minimax

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

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

While most RISC-V implementations don't use microcode, it is an option if your priority is not performance. Here are just two examples: https://github.com/gsmecher/minimax https://github.com/brouhaha/glacial

RISC-V's compressed instruction (RVC) extension is intended as an add-on to the regular, 32-bit instruction set, not a replacement or competitor. Its designers intended RVC instructions to be expanded into regular 32-bit RV32I equivalents via a pre-decoder. What happens if we explicitly architect a RISC-V CPU to execute RVC instructions, and "mop up" any RV32I instructions that aren't convenient via a microcode layer? What architectural optimizations are unlocked as a result? "Minimax" is an experimental RISC-V implementation intended to establish if an RVC-optimized CPU is, in practice, any simpler than an ordinary RV32I core with pre-decoder. While it passes a modest test suite, you should not use it without caution. (There are a large number of excellent, open source, "little" RISC-V implementations you should probably use reach for fi