[tverbeure]

I have designed large FPGAs with 5 soft CPUs. They’re immensely useful as programmable replacements of very complex FSMs and their use of FPGA resources is marginal.

One example: our vendor had an FSM to quickly save and restore trained SERDES parameters. We replaced that with a tiny CPU and it allowed us to make training decisions that could be changed without resynthesis.

Similarly, Altera themselves use a Nios CPU for their DDR4 DRAM controller IO training.

There are so many other possibilities. In one case, we fixed a corner case bug in a HW I2C controller by bit-banging the protocol.

Soft CPUs cost a few thousands gates, one or 2 BRAMs which is totally fine if you have some left. It’s no different than having tons of tiny controller CPUs in large ASICs (which literally everybody does these days.)

What makes the Vexriscv (and Nios and Microblaze) FPGA friendly is that they don’t require zero latency access to the register file. You can use BRAM instead. FF based register files are murder on the FPGA routing fabric.

[brucehoult]

> Soft CPUs cost a few thousands gates

SeRV implements RV32I and uses 125 LUTs in Artix-7, 198 LUTs in iCE40, 239 LUTs in Cyclone 10LP. Plus 164 FF in each case. Or, apparently, 2.1kGE in CMOS.

Being bit-serial, instructions take either 32 or 64 cycles, vs 3 or 4 for many of the other small RISC-V cores, but it will run at whatever Fmax the rest of your design does, and it's often plenty fast enough.

There's also now QeRV, with the same basic design but with a 4 bit datapath: 3x faster for 15% larger size.

[thijson]

Xilinx uses a microblaze for their DDR memory controller calibration as well. Initially they didn't, and I guess the calibration wouldn't always work. Software allows much more complicated algorithms for calibration than hard coded RTL state machines. I've used soft CPU's to act as the interface between hardware and user, usually over a UART.