Learn about a hardware-based approach to performing calculations, routing digital signals, and controlling embedded systems using programmable logic and FPGAs.

FPGA stands for field-programmable gate array. At its core, an FPGA is an array of interconnected digital subcircuits that implement common functions while also offering very high levels of flexibility. But getting a full picture of what an FPGA is requires more nuance. This article introduces the concepts behind FPGAs and briefly discuss what logic gates are, how to program an FPGA, and what makes an FPGA different from a microprocessor in design.


FPGA vs Microcontroller (Or, Why Use an FPGA When a Microcontroller Would Do?)

I think we can all agree that microcontrollers have become a dominant component in modern electronic design. They’re inexpensive and highly versatile, and nowadays they often serve as a person’s first introduction to the world of electronics. It’s natural for us to continue using components that we’re familiar with—and, as microcontrollers become increasingly powerful, there is less and less need to consider alternative solutions to our design challenges. Nonetheless, a microcontroller is built around a processor and processors come with fundamental limitations that need to be recognized and, in some cases, overcome.

So when would an engineer reach for an FPGA over a microcontroller? The answer comes down to software vs hardware.

A processor accomplishes its tasks by executing instructions in a sequential fashion. This means that the processor’s operations are inherently constrained: the desired functionality must be adapted to the available instructions and, in most cases, it is not possible to accomplish multiple processing tasks simultaneously.


A microcontroller is built around one processor, and a processor is built around one CPU, and one CPU performs one operation at a time.


The instruction set is designed to be highly versatile and nowadays instructions can be executed at extremely high frequencies; these characteristics, however, do not eliminate the disadvantages of a software-based approach to digital design.

The alternative is a hardware-based approach. It would be extremely convenient if every new design could be built around a digital IC that implements the exact functionality required by the system: no need to write software, no instruction-set constraints, no processing delays, just a single IC that has input pins, output pins, and digital circuitry corresponding precisely to the necessary operations. This methodology is impractical beyond description because it would involve designing an ASIC (application-specific integrated circuit) for every board. However, we can approximate this methodology using FPGAs.


What Is a Field-Programmable Gate Array?

A good name can be quite informative, and I would consider “field-programmable gate array” to be a fairly good name. An FPGA is an array of logic gates (well, sort of—see below), and this array can be programmed (actually, “configured” is probably a better word) in the field, i.e., by the user of the device as opposed to the people who designed it. Let’s take a closer look at these essential characteristics.

Logic gates (AND, OR, XOR, etc.) are the basic building blocks of digital circuitry. It’s not surprising, then, that a digital device that is intended to be highly configurable (that is, "field-programmable") would consist of numerous gates that can be interconnected in a customizable way.

However, an FPGA is not a vast collection of individual Boolean gates. This would be a very suboptimal way to provide configurable-logic functionality because it would not take advantage of the fact that common operations can be implemented much more efficiently as fixed modules. The same principle is evident in the world of discrete digital ICs. You can buy ICs that consist of AND gates, OR gates, and so forth—but you wouldn’t want to build a shift register out of individual gates. Instead, you would buy a shift register IC.

An FPGA, then, is much more than an array of gates. It’s an array of carefully designed and interconnected digital subcircuits that efficiently implement common functions while also offering very high levels of flexibility. The digital subcircuits are called configurable logic blocks (CLBs), and they form the core of the FPGA’s programmable-logic capabilities:



The CLBs need to interact with one another and with external circuitry. For these purposes, the FPGA uses a matrix of programmable interconnects and input/output (I/O) blocks. The FPGA’s “program” is stored in SRAM cells that influence the functionality of the CLBs and control the switches that establish the connection pathways.

A detailed explanation of a CLB’s internal structure and operation would require an entire article (if not multiple articles). The general idea is that CLBs include look-up tables, storage elements (flip-flops or registers), and multiplexers that allow the CLB to perform Boolean, data-storage, and arithmetic operations.

An I/O block consists of various components that facilitate communication between the CLBs and other components on the board. These include pull-up/pull-down resistors, buffers, and inverters.


Field-Programmable Logic (Or, How Do You Program an FPGA?)

How do we go about turning an array of CLBs into a digital circuit that does precisely what we want it to? At first glance, it seems like a rather complicated task. Indeed, FPGA implementation is generally considered more difficult than programming a microcontroller. However, FPGA development does not require thorough knowledge of CLB functionality or painstaking arrangement of internal interconnects, just as microcontroller development does not require thorough knowledge of a processor’s assembly-language instructions or internal control signals.

Actually, it is somewhat misleading to present an FPGA as a standalone component. FPGAs are always supported by development software that carries out the complicated process of converting a hardware design into the programming bits that determine the behavior of interconnects and CLBs.

This leaves us with an important question, though: How do we “explain” to the software what the FPGA hardware needs to do?


Hardware Description Languages

It turns out that people have created languages that allow us to “describe” hardware; they’re called (very appropriately) hardware description languages (HDLs), and the two most common are VHDL and Verilog. Despite the apparent similarity between HDL code and code written in a high-level software programming language, the two are fundamentally different. Software code specifies a sequence of operations, whereas HDL code is more like a schematic that uses text to introduce components and create interconnections.



                    1	library IEEE;
2	use IEEE.STD_LOGIC_1164.ALL;
3	entity circuit_2 is
4	    Port ( a : in  STD_LOGIC;
5	           b : in  STD_LOGIC;
6	           c : in  STD_LOGIC;
7	           d : in  STD_LOGIC;
8	           out1 : out  STD_LOGIC;
9	           out2 : out  STD_LOGIC);
10	end circuit_2;
11	architecture Behavioral of circuit_2 is
12		signal sig1: std_logic;
13	begin
14		sig1 <= ( a and b );
15		out1 <= ( sig1 or c );
16		out2 <= (not d);

17	end Behavioral;

A digital circuit and the corresponding VHDL code. See this article for more information.


AAC has quite a few articles that can help you to gain familiarity with HDL techniques. Our article on getting started with FPGAs is a good place to start if you’re interested in Verilog and you can also learn more about hardware description languages in this introduction to VHDL.



I hope that you now understand the basic characteristics of programmable-logic devices and their potential advantages with respect to processor-based systems. Modern FPGAs are sophisticated, high-performance devices that can be somewhat intimidating for those who are accustomed to using microcontrollers for gathering data, controlling ASICs, and performing mathematical operations. You might find, however, that in some applications the improved performance and versatility are worth the additional design effort.



1 Comment