VexRiscv: A Modular RISC-V Implementation for FPGA

Since an FPGA is just a sea of digital logic components on a chip, it isn’t uncommon to build a CPU using at least part of the FPGA’s circuitry. VexRiscv is an implementation of the RISC-V CPU architecture using a language called SpinalHDL.

SpinalHDL is a high-level language conceptually similar to Verilog or VHDL and can compile to Verilog or VHDL, so it should be compatible with most tool chains. VexRiscv shows off well in this project since it is very modular. You can add instructions, an MMU, JTAG debugging, caches and more.

When you build a CPU in FPGA, you generally have to make one of three choices. You can roll your own, which is great fun but requires a lot of work both on the design and the associated tools, for example, a cross-compiler or operating system. You can “borrow” an existing architecture or design which may or may not be legal, depending on what you pick. You can also use a commercial offering. While some of these are free in some circumstances, you’ll pay for anything substantial.

This open implementation offers you an easy way to leverage some great tools. There’s a debugging interface for GDB and a FreeRTOS port. You have a 32-bit part that can achieve 1.16 Dhrystone MIPS/MHz even with all features turned on. This is comparable to commercial 32-bit processors.

The documentation is good, too. You can simulate the CPU on a Linux system. There are implementation numbers for some common FPGAs, too. For example, a Cyclone V chip can support 115 MHz to 187 MHz, depending on options. Even a Cyclone II can run a bare-bones version at 156 MHz or a tricked out version at 92 MHz.

There’s even a complete system on chip design included as an example. Honestly, embarking on such a custom project wouldn’t be a half-hour project. But with the documentation provided, you could either learn a lot or get a great head start on fielding a substantial processor in an FPGA. There’s even an example of adding a completely new instruction module.

The AMBA bus usually comes without restrictions as they like having it an widely used standard rather than a money revenue. However if you are concerned there is plenty of open source alternatives like the wish bone architecture.

Yeah, but the fabrics I’ve seen based on AMBA as a basis LOCK OUT direct GPIO at the core CPU clock speed. Your only way to get high-speed bare metal GPIO is via DMA hacks – if that’s not blocked. I think this has to do with IP licensing and/or restrictions on what can be broken-out at native clock speeds on the I/O. Without such restrictions, licensees of e.g., ARM IP would not have to PAY-FOR/LICENSE on-die raw break out.

Why would somebody want to run an rtos on a cpu implementation on an FPGA? An rtos is a kludge to allow deterministic behavior on a fundamentally non deterministic platform. A cpu implementation on an FPGA is a kludge to allow the flexibility of software. if you have an FPGA in your system, surely it would always be better to run whatever functionality you would put on an rtos directly in the gates

I’m sure there are many reasons, but the most common one I’ve seen is “we already have an FPGA in this product anyway, so let’s cram an mcu in there (along with the custom logic the FPGA was added for) to avoid adding another part to the BOM”.

Using an FPGA _just_ to carry an mcu would indeed be a strange choice, but I don’t think that’s what’s going on most of the time.

The main reason the developer (whom I’ve had several back and forth interchanges about VexRiscv and SpinalHDL…all improving my situation and his project…) is doing this is that you can cut this to an FPGA and test ideas right out of box.

Try doing an ASIC approach to this (which is why I took @Rabs a bit to task in my direct reply to them…Really???).

You won’t get there. FPGAs let you test ideas out far, far more thoroughly and quickly than the old-school way. No, it’s not the same as ASIC- but you can have it proven out pretty thoroughly beforehand if you’re doing the “right” things on the FPGA.

Want to try out SiFive’s core? Get an Arty board.
Want to compare VexRiscv, versus ORCA, Rocket, f32c, or Pulpino? Pour it onto the same Arty.

Depending on your application, it might work out nicely enough.

Calling it a “kludge” is _*COMPLETELY*_ failing to understand the space. It’s a brown paper bag over the head moment, to be blunt.

Well if you needed the FPGA for something, and also need the RTOS (e.g. there is existing code that does what you need).

It would be highly unusual, pretty sure it was mentioned just as an example of what you can do with RISC-V rather than a genuine use case for FPGA. It might be a good way to teach yourself though, given that RISC-V chips are not yet amazingly common.

It’s not just intended for FPGA’s. Having said this, sometimes you have a design where you need to get most of it onto a larger FPGA (*waves hand*) and while I don’t need FreeRTOS (which isn’t a kludge…fwiw…it’s drawing a deterministic box around the system design…) I do need a baremetal CPU for a portion (it’s several feature functions on a single chip…) and this is about the same as a Cortex M0 at clock in overall performance. So, I add a bunch more parts on my board, or I implement this.

It doesn’t suit your applications…we get that. It doesn’t make for a “kludge” and you do yourself no favors by calling it so.

It should be noted that SpinalHDL should be properly compared to Chisel, which is the Scala EDL (Embedded Design Language) that the RISC-V project uses to generate Rocket Cores with. The author of SpinalHDL took it from that general vein, according to his FAQ. It’s not intended to do Scala functions to gate logic, but it’s a higher-level abstraction on VHDL/Verilog that you can get much more mileage and function out of.