How Does an FPGA Work?

Why Use an FPGA?

Hopefully this tutorial has given you a warm fuzzy feeling for how FPGAs actually work, but why would you use one?

Usually when this question comes up it's in the context of choosing between using a processor or creating a custom design with an FPGA. Lots of people know how to code, far fewer understand how to create designs for FPGAs. Writing code is often easier to create complex behavior and to drastically change how something is implemented.

However, FPGAs can be far more efficient in terms of processing time as well as offering very tight timing. To illustrate this, let’s look at a trivial example of turning an LED on when you press a button. If you wrote code to do this with something like an Arduino, the processor would run a small loop of code that would read the state of a pin then update the state of another pin based on that value.

If you optimized the code you could probably get this to update in the millions of times per second. That may sound great but let’s look at what it would look like with an FPGA. In the case of simply connecting a button to an LED with an FPGA, you simply connect the button and the LED. The value from the button passes through some input buffer, is fed through the routing matrix, then output through an output buffer. This process happens continuously all the time. The only delay comes from the switching delays of the transistors in the chip, which are incredibly small.

To expand on this, let’s now add a microphone to our design. We could take samples from the microphone and do some processing on it to figure out the frequencies in the captured audio. From some first hand experience, I know this is pretty hard to do on a small microcontroller in real time with any decent sampling rate. The processor needs to juggle reading in samples from the microphone, storing them in some buffer, performing a bunch of math, then output the values to maybe a display of LEDs. Each of these steps takes time and the processor can only really do one at a time.

With an FPGA, you could dedicate a small piece of your design to reading in samples from the microphone. This could then hand off the samples to a buffer, which, when full, would hand them off to a circuit that would do the calculations. That circuit could then hand off the results to another circuit that would display them on some LEDs.

Each of these stages would operate entirely independently from one another since they simply exist in hardware. They aren’t lines of code competing for processor time.

Now imagine we still want the button hooked up to the LED. Our previous spectacular response time of a millionth of a second is now an abysmal fifth of a second because we can’t spare the processor time to read the button that often. However, in the FPGA the button and LED are still just connected together and responding at the near instantaneous speed as before.

This independence makes FPGAs a fantastic candidate for controlling anything that requires tight timing. For example, the WS2812B LED (aka NeoPixel) requires a tightly timed stream of pulses to write data to them. When you use a microcontroller, you usually need to write some inline-assembly just to get the timing of the pulses to be accurate enough. You also need to disable interrupts as any stalls would be detrimental to the signal.

With an FPGA, it is simple to create a series of tightly controlled pulses to drive these LEDs and you don’t need to worry about anything else in your design conflicting with the timing.