This has nothing to do with performance or hardware CPU development.

FPGA-specific soft cores like VexRiscv and NaxRiscv are immensely useful for anything involving state machine logic or glue code that you do not want to implement in-fabric.

Peripherals like on-chip MMCMs/PLLs, on-board I2C and SPI peripherals, etc. with complicated initialization routines or communication flows or sequencing are very easily handled in a soft CPU.

Soft CPUs can also be used like high-powered programmable in-circuit logic analyzers: without rebuilding a potentially massive FPGA bitstream, you can probe/observe/inspect, inject/alter any signals or buses you pipe to the CPU. VexRiscv is far more pleasant to use than any vendor ILA IP.

Soft CPUs also normally utilize FPGA LUTRAM/BRAM resources, enabling whatever program to run with hard real-time latency consistency.

this guy gets it - softcores are for giving people access to your IP without forcing them write their own RTL. it's literally the exact same thing as an embedded scripting language (i.e., vm interpreter.......) in a C/C++ program.

Also, soft cpus without strict performance and power requirements are really easy to implement with modern toolchains. In one quarter you can take an undergraduate who doesn't even know digital design and have them make a cpu core as a final project, and they can make a decent one.

HW is actually really hard. If you can use a soft core to simplify the overall design and suck up a bunch of peripheral logic it's probably a good idea. Then the engineers can spend their time focusing on getting the hard parts of the design correct.

Sometimes you just need a microcontroller to handle some tasks that would be immensely complicated to do yourself. Or maybe you want custom instructions that make use of extra logic on the fabric. I use a RISC-V in my design but most of the chip is dedicated as a modem, I just needed a way to easily send commands and receive telemetry without bit banging hundreds of pins. Another nice thing about using a CPU is that the logic blocks are reusable. I could write a bunch of verilog to receive data from an ADC once a second, average some samples, convert to units, and then send them out as ASCII but now those logic blocks are sitting idle 99.9% of the time. Instead I could have the CPU convert the data and then get back to work on other any other tasks using the same logic blocks. It's certainly possible to reduce area usage by trying to reuse blocks for other functions but it's a lot more work for the engineer.

You wouldn't have only a soft CPU on an FPGA, that's a waste of time and money.

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.

> 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.

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.

Fpga are great at some things but they are pretty difficult with others. There are many applications where you can use the CPU as the control block while keeping fpga for other reasons. Furthermore keeping the cpu inside the fpga means you get to have direct access to many knobs and settings.

For example I worked on a project that used fpga to mux audio/video. It simply redirected digital pins. However the internal cpu was used to control/decide what to mux, when and how.

It could’ve been all done in fpga but that would’ve been more work (difficult/tricky/inflexible). Instead we had a small core that run a simple program and communicated to external world.

Aside from the legitimate use cases mentioned by the sibling comments, it's just fun to run a soft CPU. There's something that tickles me about setting up a computer that can run real software, especially if it's one you've had some part in designing.