Why implement microcontroller in FPGA?

Question

I am currently "investigating" FPGAs, what they can do, how they do it etc.

In more than one place (for example here) I have seen projects that implement a simple microcontroller with FPGA.

So my question:
I would like to know, what is the purpose of doing such implementations? Why use a microcontroller implemented in FPGA instead of having a micro on board? What are benefits? And perhaps also what are downsides?

Answer 1

Benefits:

• blazingly fast interface between the microcontroller and any custom interface or I/O logic on-chip.
• customizable processor and debug interfaces
• also, often easier control logic than writing the control code with, say, VHDL

Downsides:

• Possibly more expensive FPGA is needed to fit both the microcontroller and the custom logic, compared to just having the custom logic on the FPGA
• Possibly more difficult to implement, especially with memories and if the core is complex, than a ready-made microcontroller on a separate chip.

Answer 2

If your project is going to use an FPGA for the grunt work, and it has the spare capacity, why would you go to the expense of an extra chip when you can just implement it in the FPGA?

For many procedural control environments it can be considerably easier to implement the required setup in a language like C than trying to do it in VHDL or Verilog. By adding the microcontroller into the FPGA you get the best of both worlds - the power of the VHDL / Verilog etc for the logic and interfacing systems, and the simplicity of a procedural language for the core control and management systems.

Answer 3

In extension to the answers of Majenko and PkP:

This trend of embedding a CPU into the FPGA design has lead to several heterogeneous systems like:

• Xilinx' Zynq-7000 family
• Altera's Arria/Cyclon/Stratix SoC FPGAs
• MicroSemi's SmartFusion FPGAs

There is also an Intel Atom + Altera FPGA chip on the market: http://www.altera.com/devices/processor/intel/e6xx/proc-e6x5c.html

Most free micro controllers for FPGA suffer from a bad tool chain support. Embedded ARM CPUs come with trace/debug support, compilers (gcc tool chain) and full linux support. Here is a survey presented at FPL 2014: http://dx.doi.org/10.1109/FPL.2014.6927482

Edit 1:
There is also the class of PSoC (Programmable System on Chip) devices from Cypress. These devices include a micro controller (M8C, 8051, ARM Cortex M0 or Cortex M3) and classic SoC integrated I/O controllers or devices (I²C, SPI, Timer, CAN, DAC, ADC, OpAmp, ...) and a programmable part. This part is not as fine grain programmable as classic FPGAs, but it can be used to implement addition I/O controllers or built hardware accelerators. PSoC allows you to use analog components in your design.
http://www.cypress.com/psoc/?source=CY-ENG-HEADER

PSoC overview:
_{(source: electronicdesign.com)}

Answer 4

If you just needed a microcontroller, and didn't have an FPGA, it would be unusual to use a FPGA with microcontroller firmware. However, not all projects grow in that direction. Many tasks have clear need for a FPGA, but eventually come across a task which really isn't suitable for a VHDL solution. Sometimes a problem is simply best handled by a general purpose CPU. Or, sometimes it's the other way around: some tasks are simply not suitable for a general purpose CPU -- they need parallelism.

At that time, you have a choice. You can either add an additional chip to your device, or you can realize you have a bunch of spare gates on the FPGA you're not utilizing. License a little IP, and you can have a working general purpose CPU in no time!

Another interesting detail is that you can customize some microcontroller firmwares. I know of projects which embedded a Power PC, but stripped out all of the gates needed for floating point support, and a good chunk of the branch prediction. This made it small enough to fit side-by-side with the VHDL based firmware.

Answer 5

There are several valid reasons for instantiating a microprocessor or microcontroller in an FPGA. Here are three:

1. You just want to learn about the operation of a processor. FPGAs give you infinite ways to probe what's happening inside the processor as it executes code. This is just for learning.

2. You are implementing a big system that requires the hardware-level speeds of an FPGA (faster than software executing on a microprocessor) but your design requires a complex state machine, which is more easily implemented using software running on a simple processor like the Xilinx PicoBlaze than in a hardware FSM. Note that a PicoBlaze can run as fast as 240MHz in the latest FPGA process technologies and that the PicoBlaze processor executes an instruction every two clock cycles, so you get a fast, consistent state machine that's easily programmed in software.

3. Expanding on (2), you need a state machine that can handle interrupts. Processors are really good for this because they already know how to safely save and restore state before and after servicing the interrupt.

Here is one caveat: If you want a fast processor with a standard instruction set and a big development ecosystem, then you want a fast, hard-core processor like the two ARM Cortex-A9s in a Xilinx Zynq SoC. The FPGA fabric in the Zynq SoC still allows you instantiate more processor cores in programmable logic but the ARM Cortex-A9s can run standard operating systems such as Linux and standard IDEs such as Android.

In between the ARM Cortex-A9 and PicoBlaze, there are many soft processors you can implement with programmable logic available from many sources. Some people like to roll their own processors and that's a great educational activity. However, microprocessors need software development tools and creating/debugging those tools requires orders of magnitude more effort than creating the processor itself. You must always trade off the possible benefit of a custom microprocessor against the time and effort needed to create/debug the processor core and the tools.

Full disclosure: I work for Xilinx but I'm pretty sure I didn't state that FPGAs are always the solution. If a 50-cent microcontroller can do the job, you're better off using that. FPGAs and Zynq SoCs are for projects that require heavy lifting beyond the abilities of microcontrollers.

Answer 6

Sometimes you might use an FPGA because you have software that runs on a long-obsolete and unavailable physical processor that you want to resurrect. Whilst not pin-compatible (although DIP-style mounts have been seen) this lets you be cycle accurate. A pure software emulation on a commodity microprocessor is unlikely to be so. For example apple2fpga