How an FPGA is programmed

Lesson 01 said that programming an FPGA means filling its configuration memory so the chip becomes your circuit. This lesson follows the whole path from the text you type to the configured device. You do not need to run any tool yet. The aim is that when you open Vivado, Quartus Prime, Radiant or a Yosys script in later lessons, every step on the screen has a name and a purpose you already know.

The flow in one picture

The FPGA design flow. Each stage consumes the output of the one before it. Constraints enter at synthesis and again at place and route. Simulation can be run on the RTL or on any later netlist.

The stages are the same in every vendor’s tool and in the open-source flow. The names on the buttons differ, and the section near the end maps them.

Stage 1: RTL

You begin by writing a description of the circuit in a hardware description language, usually Verilog, SystemVerilog or VHDL. The description is called RTL, for register transfer level, because it says what value each register takes on each clock edge and what logic sits between the registers. It is plain text. A small project is a few files of a few hundred lines. A large one is thousands of files.

RTL is not a program. Every statement in it exists at once in the finished chip. Lesson 05 is where you write your first file. For now, think of the RTL as the source of truth that every later stage must preserve exactly.

Alongside the RTL you write constraints. The most important constraint tells the tools how fast the clock runs. A line that says “clk has a period of 10 ns” is what makes the rest of the flow check that your logic settles in time. Other constraints assign signals to physical pins and set the voltage standard of each pin. AMD stores them in XDC files, Altera and Lattice in SDC files, and both formats are Tcl-like text. Constraints are not optional extras. Without a clock constraint the tools cannot tell you whether the design will work, and without pin constraints they will put your LED on a random pin.

Stage 2: Synthesis

Synthesis reads the RTL and turns it into a netlist, a list of logic primitives and the wires between them. The primitives are the ones the target device offers: look-up tables, flip-flops, carry chain cells, block RAMs, DSP blocks and I/O buffers. An if statement becomes a multiplexer, an addition becomes a chain of carry cells, a case statement becomes a few LUTs, and an array in your code becomes a block RAM if it is large enough and written in a form the tool recognises.

Synthesis also optimises. It removes logic whose output is never used, merges duplicate logic, and simplifies Boolean expressions. If you write a 32-bit counter and only read the top bit, synthesis keeps all 32 bits because each bit feeds the next, but if you compute a value and never connect it to anything, it disappears. The report synthesis writes tells you how many LUTs, flip-flops, RAMs and DSPs the design used, and you should read it every time. A design that unexpectedly uses zero resources has usually had its output optimised away because of a wiring mistake.

The netlist that comes out is still device-independent in one sense (it has no idea where on the chip anything goes) and device-specific in another (it uses that family’s primitives). Synthesis of a small design takes seconds. For a large one it takes tens of minutes.

Stage 3: Place and route

Place and route, which AMD calls implementation and Altera calls fitting, takes the netlist and the device and makes two decisions. Placement chooses a physical site for every primitive: this LUT goes in that slice, this flip-flop goes next to it, this RAM goes in block RAM column 3. Routing then chooses, for every wire in the netlist, a path through the programmable interconnect from its source to all its destinations, closing a specific set of switches.

Both decisions are constrained by timing. The tool knows the delay of every LUT and every routing segment, and it knows from your constraints that the clock runs at 100 MHz. For every path from one flip-flop to the next it adds up the delays and checks that the sum fits in 10 ns, less the time the flip-flops themselves need. If it does not, the tool tries a different placement, a shorter route, or both. This is why place and route takes minutes on a small design and hours on a large one, and why it sometimes fails. The result is a timing report that says, for the worst path in the design, how much slack remains. Positive slack means the design will work at the requested clock. Negative slack means it will not, and you must fix the design or lower the clock.

Stage 4: Bitstream generation

With every site and every switch decided, the tool writes the bitstream. This is the file that contains one bit for every configurable element on the chip: the 64 bits of each LUT’s truth table, the mode bits of each flip-flop, the state of each routing switch, each I/O block’s drive strength and standard, and the initial contents of every block RAM. The file is specific to one exact device. A bitstream for an XC7A35T will not configure an XC7A100T, even though both are Artix 7.

Bitstreams are large. The AMD XC7A35T, a small part, needs about 17.5 Mb of configuration data, roughly 2.2 MB on disk. A large device needs hundreds of megabits. The format is proprietary at AMD and Altera, and the open-source community has reverse-engineered it for Lattice iCE40 and ECP5, several Gowin families and some AMD 7 Series parts.

Bitstream encryption and authentication belong to the hardware security topic.

Stage 5: Configuration

The last step is getting the bitstream into the chip. How that works depends on which of three memory technologies the device uses to hold its configuration, and that choice shapes everything about how the part behaves at power-up.

SRAM-based devices

Most FPGAs, including all AMD and Altera parts and most Lattice parts, hold their configuration in static RAM. SRAM is fast, is built on the same leading-edge process as the logic, and can be rewritten any number of times. It is also volatile. When power is removed the configuration vanishes, and at the next power-up the chip is blank.

An SRAM-based FPGA therefore needs something to load it every time it starts. In a product that is usually a small serial flash chip on the board next to the FPGA. At power-up the FPGA reads the bitstream out of the flash over a SPI-like interface, which takes from a few milliseconds to a few hundred milliseconds depending on the size of the bitstream and the width of the interface. Alternatively a processor on the board can feed the bitstream through a parallel or serial configuration port. On the bench you bypass all of this and load the bitstream directly into the SRAM over JTAG from your PC, which is what the “program device” button does. A JTAG load survives until power is removed and is lost after that.

Flash-based devices

Some families store the configuration in on-chip flash memory. Microchip’s PolarFire and IGLOO2 families and Lattice’s MachXO families work this way, and the Lattice iCE40 parts have a one-time-programmable on-chip memory as an option. A flash-based device is live within microseconds of power-up because there is nothing to load, it does not need an external configuration chip, and the design cannot be read from a bus on the board. The costs are a process technology a generation or two behind the SRAM parts, a limited number of rewrite cycles (hundreds to thousands rather than unlimited), and slower programming. Flash parts suit low-power, security-sensitive and instant-on applications.

Antifuse devices

An antifuse is a link that is open until a programming voltage permanently closes it. Antifuse FPGAs, made by Microchip (formerly Actel) for space and defence, are programmed once and can never be changed. Their configuration is immune to radiation-induced upsets and cannot be read back, which is why they fly on satellites. They are also expensive, offered in small logic capacities and on old processes, and a mistake in the design means a discarded chip. Their place is the space and high-reliability topic.

Technology	Volatile	Rewrite cycles	Needs external loader	Start-up time	Typical use
SRAM	Yes	Unlimited	Yes (flash or processor)	Milliseconds to hundreds of ms	Almost everything
Flash	No	Hundreds to thousands	No	Microseconds	Low power, instant-on, security
Antifuse	No	One	No	Microseconds	Space, defence

Who calls what

Every vendor packages the same stages under different names. The table maps them. Microchip (Libero SoC), Efinix (Efinity) and Gowin (Gowin EDA) follow the same pattern and are covered on the toolchains reference.

Stage	AMD Vivado	Altera Quartus Prime	Lattice Radiant / Diamond	Open-source flow
RTL entry	Any editor, or the Vivado editor	Any editor, or the Quartus editor	Any editor, or the built-in editor	Any editor
Constraints	XDC (Tcl)	SDC plus QSF for pins	SDC plus PDC (Radiant) or LPF (Diamond) for pins	PCF (iCE40) or LPF (ECP5) for pins, SDC for clocks
Synthesis	Vivado synthesis (`synth_design`)	Analysis and Synthesis	Synplify Pro or Lattice Synthesis Engine	Yosys
Place and route	Implementation (`opt_design`, `place_design`, `route_design`)	Fitter	Map, place and route	nextpnr
Timing report	`report_timing_summary`	Timing Analyzer	Timing analysis	nextpnr timing report
Bitstream	`write_bitstream`, produces .bit	Assembler, produces .sof and .pof	Bitstream generation, produces .bit	icepack, ecppack, gowin_pack and others
Configure	Hardware Manager	Programmer	Programmer	openFPGALoader, iceprog, ecpprog
Simulation	Vivado Simulator (xsim)	Questa (bundled edition)	ModelSim or Questa (bundled)	Icarus Verilog, Verilator, GHDL, nvc

On the open-source column: Yosys synthesises for many families, nextpnr places and routes for Lattice iCE40 and ECP5, Gowin and some others, and the packers and programmers are small family-specific tools from the same community. At the time of writing the flow is complete for Lattice iCE40 and ECP5 and for Gowin parts, usable with caveats for some AMD 7 Series devices, and absent for current Altera parts. The open-source toolchains topic tracks the state of play.

Simulation sits beside the flow

One box in the diagram is not on the main path. Simulation runs your RTL in software, with stimulus you write, so that you can check its behaviour before spending minutes on synthesis and place and route. You can also simulate the netlist after either stage, with real delays annotated. Simulation is where you will spend most of your time as a designer, and lesson 06 is devoted to it.

Exercise

Download one vendor tool and open it, without creating a project. Vivado (the free ML Standard edition), Quartus Prime Lite, or Radiant will all do. If you would rather stay with open-source tools, install the OSS CAD Suite from YosysHQ, which bundles Yosys, nextpnr and the programmers. Then find, in the menus or the documentation, the button or command for each of the five stages in this lesson and write down what it is called. You now have a map of the tool before you have used it.

For a second exercise, find out which configuration technology the FPGA on any development board you own uses, and whether the board carries a configuration flash. The reference manual will say.

Summary

The flow runs RTL, synthesis, place and route, bitstream generation and configuration, and every vendor’s tool follows the same five stages under its own names.
Synthesis turns text into a netlist of device primitives. Place and route puts those primitives on physical sites and wires them up, checking timing against your constraints as it goes.
The bitstream is a device-specific file containing one bit for every configurable element on the chip.
SRAM-based devices are volatile and load from flash or a processor at power-up. Flash-based devices are instant-on and limited in rewrites. Antifuse devices are programmed once and used where upsets are unacceptable.
Constraints are inputs to the flow. Without a clock constraint there is no timing check, and without pin constraints there is no connection to the board.