One of the ways people use FPGAs is to have part of the FPGA fabric hold a CPU. That makes sense because CPUs are good at some jobs that are hard to do with an FPGA, and vice versa. Now that the RISC-V architecture is available it makes sense that it can be used as an FPGA-based CPU. [Clifford Wolf] created PicoSOC — a RISC-V CPU made to work as a SOC or System on Chip with a Lattice 8K evaluation board. [Mattvenn] ported that over to a TinyFPGA board that also contains a Lattice FPGA and shows an example of interfacing it with a WS2812 intelligent LED peripheral. You can see a video about the project, below.
True to the open source nature of the RISC-V, the project uses the open source Icestorm toolchain which we’ve talked about many times before. [Matt] thoughtfully provided the firmware precompiled so you don’t have to install gcc for the RISC-V unless you want to write you own software. Which, of course, you will.
The RISC-V isn’t the first SOC available for FPGAs, although some of the ones commonly used have cloudy pedigrees because they emulate some other non-open CPU. The first part of the video covers how to get started with the RISC-V. Then [Matt] explains how he added support for the smart LEDs into his design.
The addition is written in Verilog, so if you don’t read that language, you might want to brush up before you tackle this project. Once that design proved out, he integrated the LED driver with the CPU.
Although SOC hardware and software design isn’t a new idea, it is amazing that you can now do it with open tools like gcc, icestorm, and an open source CPU core. If you want to get started with something a little less daunting, you can always check out our FPGA boot camps. If you’d rather use ARM cores and Xilinx FPGAs, that’s a free — though not open source — option now, too.
I really wish I had more hours in my day to work with this stuff. Very interesting. Thanks!
>That makes sense because CPUs are good at some jobs that are hard to do with an FPGA, and vice versa.
I would like you to think about that sentence three more times.
FPGAs are bad at things that CPUs do, therefore, implement a CPU inside an FPGA. Did this solve the original question?
I actually considered that when I wrote it but I think most people know what I mean. It would be like saying cars aren’t good at carrying cargo unless you put a car top carrier on it. If you insist on it I could say “CPUs are good at some jobs that are hard to do with an FPGA without a CPU” but then someone would post that I must get paid by the word and so I insulted their intelligence by adding the obvious.
I think the point is that FPGAs just can’t do some things as-is, so you have to implement a CPU in it – not that it’s in any sense efficient to do so, because obviously constructing a CPU out of the FPGA is not going to magically make the FPGA any better or different than it actually is.
>” It would be like saying cars aren’t good at carrying cargo unless you put a car top carrier on it.”
That’s not quite the same thing, because you’re adding to the car. What you have to do is work within the means of the car.
What you were saying is literally more like, “This 486 is slow. I’ll emulate an i7 inside it, that’ll make it faster”. Obviously not.
Yes and that softcore CPU will be 10x slower than an equivalent hard CPU on the same manufacturing process
Not at all. FPGA is fast but it’s an expensive way to make a CPU and chews a lot more power.
If I want to make less than a hundred devices, an FPGA is cheaper than manufacturing CPU (or ASIC). Even though the FPGA takes many many times the silicon area to emulate the soft CPU design. FPGAs are cheap for problems that are specialized or very low volume (hobbyist).
If I had time, and money, and more knowledge I’d love to make some slow, low-power, cheap microcontrollers for hobbyists. Perhaps at 0.35 micron technology, which seems to be popular and inexpensive for ASICs. Some ideas: RISC V w/ HDMI in/out for doing overlays; RISC V w/ full 32-bit external bus (VMEbus? PCI?); RISC V w/ Software Defined Radio (SDR); some kind of switched fabric or bus to connect all these RISC V’s together nicely (low speed HyperTransport?).
Are you certain you’re comparing across the same process (and same metal stack)? A factor of 10 is the commonly quoted figure. FPGAs are fast, but ASIC is faster for the same RTL, especially when you are routing large data buses back and forth across the chip. The main sore points are slow logic elements and poor routing resources. This is tempered by the fact that a only a slim minority of companies tape out on the newest, fastest nodes, so FPGAs are on better processes than most companies will be prototyping their ASICs on.
The point is that some things are difficult and inefficient to implement with logic that’s entirely defined in gate structure, but get much easier when you can define behavior in code. Dedicating some of that gate structure to executing code opens up a large, important box of tools.
Yeah, but then you’re getting into the territory of “shouldn’t have used an FPGA in the first place”.
A fixed algorithm is -usually- more efficient directly implemented than run through an emulated CPU core, and even when you need the CPU, such as when you have a lot of branches in your code, slapping an actual CPU next to the FPGA would be more efficient because FPGA gates use a lot more electrical power for the same bang.
What’s been missed in most of these replies is that there are some tasks that a CPU *can’t* do, and that would be horrifically difficult to implement directly on the FPGA without a soft-core. For instance, what about a soft CPU that allows for dynamic control of a FPGA fabric for transforming a 1080p video stream with minimum latency? Sure an i7+gpu desktop could come close, but at the cost of latency, size and power. What if said device needs to be packaged in to a small portable box, and run from batteries?
> That makes sense because CPUs are good at some jobs that are hard to do with an FPGA, and vice versa
That makes sense because libc is good at some jobs that are hard to do without libc.
libc is implemented in C but rare is the C project that is better off without it.
Just reading the phrase ” FPGAs are bad at things that CPUs do, therefore, implement a CPU inside an FPGA. Did this solve the original question? ” reminded me of the same thing the other way around. Matthias Koch implemented his mecrisp Forth software on a RISC V in a Lattice ICE 8K FPGA. Easy board to access – but slow in comparison to the real thing. We asked SIFive to give us a RISC V board, Matthias could then carry over his implementation to the real silicon – quite a difference in execution speed. https://forums.sifive.com/t/announcing-mecrisp-quintus-a-native-code-forth-for-rv32im/1107 and http://mecrisp.sourceforge.net/
So, you have mecrisp running on RISC V – what next? mecrisp was ported by Matthias to the microbit at the time and a small test program was adapted, see https://wiki.forth-ev.de/doku.php/en:projects:a-start-with-forth:start0 chapter 12 . should be easy to adapt. What Does It Do – see chapter 4 Invent A Language, and more chapters there might be of interest as well.