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?

  • \$\begingroup\$ Many of these use canned IP cores, however rolling your own can be a great learning experience. \$\endgroup\$ Commented Jan 6, 2015 at 22:41
  • 1
    \$\begingroup\$ @ChrisStratton - Can you tell more, or post a link about canned IP cores? Yes, I am sure it can be a great learning experience. But that's one of the reasons I am asking this question. I wonder if it is anything more than just a learning experience. \$\endgroup\$
    – James C
    Commented Jan 6, 2015 at 22:49
  • 1
    \$\begingroup\$ Most people doing it are using something like a Microblaze, Picobloze, Nios II, etc - these are basically processor designs "in a can" (library) which you can license and put in your project. The contrast would be developing one yourself in HDL source, perhaps from the block diagram presented in your typical CS101 lecture. There are a number of interesting practicalities to contend with in turning the lecture drawing into working hardware. \$\endgroup\$ Commented Jan 6, 2015 at 22:51
  • 1
    \$\begingroup\$ See Open Cores for lots of examples of open source CPU cores. \$\endgroup\$
    – RBerteig
    Commented Jan 7, 2015 at 1:41
  • 3
    \$\begingroup\$ I have an example. We had a microcontroller go obsolete for an old product. We could not find a suitable replacement microcontroller with the right mix of peripherals. Using an FPGA with an embedded processor allowed us to implement our ideal mix of peripherals on the FPGA. \$\endgroup\$
    – kkrambo
    Commented Jan 7, 2015 at 14:47

6 Answers 6



  • 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


  • 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.
  • 4
    \$\begingroup\$ Additional benefit: simpler design, one fewer chip. \$\endgroup\$
    – DoxyLover
    Commented Jan 6, 2015 at 23:23
  • 4
    \$\begingroup\$ Additional Downside: licensing more IP \$\endgroup\$
    – Mikhail
    Commented Jan 6, 2015 at 23:29
  • \$\begingroup\$ How about power consumption as a downside? \$\endgroup\$ Commented Jan 7, 2015 at 23:23
  • \$\begingroup\$ @CraigMcQueen It's theoretically possible to generate a microcontroller in a FPGA which hasn't been produced as stand-alone hardware yet. In that case, there's no power consumption to compare. In any case, it's too device specific to be a general upside/downside. \$\endgroup\$
    – Mast
    Commented Jan 8, 2015 at 16:31
  • \$\begingroup\$ All very good comments. And well, I would say that generally FPGAs have a big power consumption, because the logic utilization is usually very far from 100% within a macrocell. This is offseted a little by the fact that FPGAs can use sophisticated power minimization techniques. The manufacturing processes (technologies) can be quite similar between an FPGA and a processor of the same era. Processors have dedicated memory blocks, as well as FPGAs. Whether these match your needs, well, depends on how lucky you are to find an FPGA that exactly matches your needs. \$\endgroup\$
    – PkP
    Commented Jan 8, 2015 at 17:02

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.

  • 11
    \$\begingroup\$ The first sentence of this answer is the main reason. This is mainly done when you already have an FPGA with some spare capacity on the board anyway. (At least) one less chip and less board complexity. You wouldn't put an FPGA on a board just to implement a microcontroller with it, but when you already have an FPGA, it's a nice way to cut down on parts cost and board complexity. At least that's why we do it. \$\endgroup\$
    – reirab
    Commented Jan 7, 2015 at 15:26

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.

PSoC overview: PSoC
(source: electronicdesign.com)


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.


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.

  • \$\begingroup\$ Warm welcome, Steven! \$\endgroup\$
    – PkP
    Commented Jan 7, 2015 at 17:58
  • 1
    \$\begingroup\$ Good answer, but who needs a state machine that can handle interupts? Interrupts are a necessary evil for fetch-decode-execute processors because handling the external stimulus requires exclusive use of the processor to run the ISR. In an FPGA, the external stimulus is handled in a separate logic block while the state machine also continues running; no need for saving and restoring state. Basically, interrupts are an imperfect solution to a problem that HDL doesn't have in the first place. \$\endgroup\$
    – Ben Voigt
    Commented Jan 7, 2015 at 20:01
  • \$\begingroup\$ You're of course correct for hardware-implemented state machines, Ben. You can always wire the "interrupt" pin as another state-machine input. However, many complex state machines are simply more comprehensible when implemented with a processor running C, or at least more comprehensible for some developers. That's when you need an interrupt. \$\endgroup\$ Commented Jan 8, 2015 at 18:55

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


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.