In short: An FPGA bitstream is the binary configuration image that loads a design's routing, logic-cell truth tables and block-RAM contents into the device's SRAM configuration cells at power-up, delivered through modes like Master SPI, SelectMAP or JTAG, and optionally protected with AES encryption and HMAC/ECDSA authentication.
What a bitstream actually is
Most mainstream FPGAs (AMD/Xilinx 7-series, UltraScale+, Intel/Altera Agilex, Lattice) are SRAM-based: the device has no fixed function until configuration memory is loaded. The bitstream is the serialized image of that configuration memory. It is not your RTL and it is not a netlist — it is the final, vendor-specific, bit-level description of every programmable element the place-and-route tool committed to.
Concretely, a bitstream encodes: the lookup-table (LUT) mask bits for each logic slice, the routing switch states that steer nets through the interconnect matrix, the initial contents of block RAM and distributed RAM, DSP block modes, I/O standards and drive strength, and clock-management (MMCM/PLL) settings. Vendor tools generate it — `write_bitstream` in AMD Vivado, Quartus Prime for Intel, Lattice Radiant/Diamond. A Kintex-7 XC7K325T bitstream is roughly 91 Mbit; an UltraScale+ VU13P runs to hundreds of megabits, which is why configuration time and flash capacity are real design constraints.
Key fact: The bitstream is organized as a stream of configuration frames — the smallest addressable unit of config memory. In 7-series an individual frame is 101 32-bit words; the bitstream header writes an address into the Frame Address Register (FAR) then streams frame data into the FDRI register.
Configuration modes
How the bitstream reaches the chip is selected by mode pins (e.g. the M[2:0] pins on 7-series), sampled at power-up. The choice trades pins for speed and determines who is the "master" of the clock.
| Mode | Master/Slave | Width | Typical use |
|---|---|---|---|
| Master SPI | FPGA drives clock | x1/x2/x4/x8 | Boot from on-board SPI flash — most common in production |
| Master BPI | FPGA drives clock | x8/x16 | Parallel NOR flash, faster boot |
| SelectMAP / slave parallel | External drives clock | x8/x16/x32 | CPU/CPLD loads fabric at high throughput |
| JTAG | External (TAP) | x1 | Bench bring-up, debug, readback |
Boot time scales with bitstream size and clock: a 91 Mbit image over x4 SPI at 66 MHz is roughly 91e6 / (4 × 66e6) ≈ 345 ms of raw transfer. For designs that must meet a PCIe 100 ms enumeration window, teams lean on x8 BPI, higher config clocks, or a two-stage boot that brings up a small first-stage design fast.
Encryption and authentication
Because an SRAM bitstream sits in external flash, it is exposed to cloning and reverse engineering. Vendors defend against this with on-chip crypto. AMD 7-series and UltraScale+ support AES-256 (GCM on UltraScale+, CBC on older parts) with the key stored either in battery-backed BBRAM or burned into one-time eFUSE. The decryptor sits in the configuration engine, so the plaintext image only ever exists inside the device.
Confidentiality alone is not enough — a tampered ciphertext could still be loaded. Modern families therefore add authentication: an HMAC-SHA256 integrity tag plus asymmetric boot authentication (RSA-2048 on Zynq, ECDSA/RSA in the UltraScale+ hardware root of trust) so the device rejects any image not signed by the holder of the private key. This is the same chain-of-trust reasoning you see across secure silicon; it is a core concern in the hardware-security and trusted-boot work done by design houses such as Avecas VLSI design services.
Key fact: If you encrypt a bitstream, you generally lose the ability to do readback and partial reconfiguration unless the flow explicitly supports it — the config engine will refuse unauthenticated frame writes once secure boot is enforced.
Readback and verification
Readback is the inverse of configuration: the config engine streams the current contents of config memory back out, usually over JTAG or SelectMAP. Engineers use it for three things. First, verification — compare the read-back image against the golden bitstream to confirm a clean load. Second, capture — because register and block-RAM state live in config cells, readback can snapshot live design state for debug, the mechanism behind Vivado's integrated logic analyzer. Third, SEU mitigation — in aerospace designs the Soft Error Mitigation (SEM) IP continuously reads frames, checks ECC/CRC, and corrects single-event upsets caused by radiation flipping a config bit.
Key fact: A single-bit flip in a routing config frame can silently misroute a net. SEM-style scrubbing on a Kintex typically cycles the whole device in tens of milliseconds, well inside the upset rate budget for most LEO missions.
Partial bitstreams and relocation
Not every bitstream configures the whole device. A partial bitstream targets only the frames inside a reconfigurable region, letting you swap one block of logic while the rest keeps running. That is a large topic in its own right — see our companion article on partial reconfiguration for the floorplanning, decoupling and ICAP-driven delivery details, and our piece on FPGA vs ASIC trade-offs for why this reprogrammability is the whole point of the technology. If you want the full configuration and security flow with lab exercises, browse the CourseTron course catalog.
Ready to go from "I generated a .bit file" to confidently debugging boot failures and signing secure images? The CourseTron FPGA Design & Configuration course walks you through every mode on real hardware. Explore the course →
Frequently asked questions
Does the bitstream contain my original Verilog or VHDL?
No. By the time the bitstream is written, your source has passed through synthesis and place-and-route into a bit-level config image. It cannot be trivially decompiled back to RTL, though an unencrypted bitstream can be partially reverse-engineered, which is exactly why encryption and authentication exist.
Why does my FPGA lose its configuration when I power it off?
Mainstream FPGAs use volatile SRAM for configuration, so the fabric is blank at every power-up and must reload the bitstream from flash or a host. Flash-based FPGAs (e.g. Microchip PolarFire, Lattice MachXO) are the exception — they are non-volatile and retain their config.
What is the difference between a .bit and a .mcs file?
A `.bit` is the raw bitstream for JTAG/direct loading. A `.mcs` (or `.bin`) is the same image formatted and often address-mapped for programming into a specific flash device, including any multi-boot or golden/update image layout.
Can I update the key or design in the field securely?
Yes. With eFUSE/BBRAM key management plus authenticated boot and multi-boot fallback, you can ship a signed update image to flash and have the device validate it before swapping over, reverting to a golden image if authentication fails.