FPGA Configuration Memory: QSPI, eMMC and Secure Boot

Choose the boot owner before choosing the memory #

“FPGA configuration memory” can describe two different systems. A conventional FPGA can act as the SPI master and clock a bitstream directly from serial NOR. A processor-equipped FPGA or adaptive SoC can instead run immutable BootROM, load platform firmware, authenticate a composite boot image and then configure the programmable logic. Some of those devices can boot from eMMC; a pure FPGA SPI configuration port cannot.

That distinction decides the interface, image format, recovery design and substitution boundary. The useful design sequence is:

• select the exact FPGA or adaptive-SoC family and its supported boot mode;
• decide which immutable block owns the first read after reset;
• budget the primary, recovery and update images before choosing density;
• define authentication, encryption, key storage and rollback policy;
• choose an orderable memory device that the boot ROM and programming tools both support;
• validate cold boot, interrupted update and recovery on production hardware.

This guide is about that system contract. The Winbond serial-flash series guide goes deeper into flash-family and suffix differences; the FPGA DDR4/DDR5 design guide covers volatile working memory after configuration. Neither QSPI NOR nor eMMC replaces external DDR.

QSPI NOR is the direct-configuration path #

AMD UltraScale and UltraScale+ FPGAs support master SPI in x1, x2 and x4 modes; UltraScale also supports an x8 arrangement made from two identical flash devices. In this topology the FPGA generates the configuration clock, issues a supported read command and consumes the bitstream directly. The flash therefore has to be awake before the FPGA begins the transaction, and its read timing has to close at the selected configuration-clock setting.

Altera Agilex devices use a Secure Device Manager (SDM) to control configuration. For Agilex 5 active-serial designs, the documented flow uses QSPI and AS x4. The current guide makes a further PCIe-specific distinction: Micron QSPI allows the boot ROM to use AS x4 for the initial firmware, while other supported flash types are read in AS x1 and require the board reset timing to preserve the PCIe enumeration window. This is exactly why “same density, Quad SPI” is not enough to approve a substitute.

Five flash details routinely change boot behaviour:

• Voltage and I/O domain. A 1.8 V MT25QU device and a 3 V MT25QL device can share a density and command family while being electrically incompatible.
• Addressing above 128 Mbit. Large devices can require 4-byte addressing or a bank/extended-address mechanism. AMD explicitly separates QSPI24 and QSPI32 modes on processor-based families; the generated image and boot-mode straps must agree with the chosen topology.
• Read command, dummy cycles and Quad Enable state. Boot ROMs implement a defined command set. A flash that needs a different mode sequence, power-up state or latency code can fail before user firmware has any chance to fix it.
• Reset and power-on behaviour. The reset pin may be dedicated or shared with an I/O function. Power-up delay, deep-power-down exit and reset recovery have to fit the FPGA's first access.
• Programming-tool support. AMD Vivado 2026.1 still asks the user to select a specific configuration-memory part. Altera's Programming File Generator likewise selects a supported flash device and uses that geometry to build the programming file. A serial-NOR datasheet alone is not tool-chain approval.

Boot-time arithmetic should use the generated, secured image rather than the nominal FPGA bit count. Headers, firmware, authentication material, alignment, compression and multiple images change the stored size. Measure configuration time from power-good to the real system-ready indication; the raw clock rate is only one term.

eMMC belongs to a processor-managed boot flow #

eMMC combines NAND, a controller and firmware behind a standardized interface. It provides far more capacity than typical configuration NOR and can hold boot firmware, an operating system, files and application data. It is still not a drop-in serial configuration device.

AMD's current Versal system software guide lists eMMC as a primary boot mode, with secure boot and fallback support. The device BootROM and platform management controller interpret a Versal Programmable Device Image (PDI), which can contain platform-loader firmware, programmable-logic configuration, processor software and other partitions. The same guide distinguishes this processor-managed flow from QSPI24, QSPI32 and OSPI modes.

Altera Agilex 5 SoCs include an HPS SD/SDIO/eMMC controller supporting eMMC up to version 5.1, while the SDM continues to own FPGA configuration and security. Agilex boot order can be FPGA-first or HPS-first. That means the team must use the exact SoC boot guide to decide where the first-stage loader, FPGA image, operating system and recovery image reside; the existence of an eMMC controller does not turn eMMC into an AS x4 flash.

Choose eMMC when the selected SoC or adaptive SoC explicitly supports the boot mode and the system needs managed high-capacity storage. Then qualify more than capacity and HS400 speed:

Managed NAND can hide bad blocks and wear management from the host, but it also adds controller firmware to the qualified system. “Same capacity and eMMC 5.1” does not prove equivalent boot latency, partition configuration, power-loss response or lifecycle behaviour.

Secure boot is enforced by the FPGA, not by the flash label #

Serial NOR protection bits, one-time-programmable regions, password functions and RPMC counters can support a secure platform. They do not by themselves authenticate an FPGA bitstream. The root of trust is the immutable BootROM or configuration security block, its provisioned keys and the policy that decides which image may execute.

For AMD UltraScale-class FPGAs, UG570 documents AES-GCM bitstream encryption and authentication using a 256-bit key stored in BBRAM or one-time-programmable eFUSE. It also documents RSA-2048 authentication and warns that designs relying on RSA authentication must follow the current mitigation guidance and enforce encryption. Security settings therefore belong to the exact device generation, not to a generic “Xilinx secure boot” checklist.

Versal uses a different chain. The 2026.1 documentation defines asymmetric and symmetric hardware roots of trust. Asymmetric boot can authenticate with RSA or ECC, while symmetric boot uses AES-256-GCM for confidentiality, authenticity and integrity. The BootROM loads and verifies the platform loader before later PDI partitions are accepted. Some eFUSE settings permanently enforce secure boot; the provisioning flow must be rehearsed on sacrificial devices before production.

Altera Agilex 5 places configuration and security under the SDM. Current device documentation lists secure boot, AES encryption, hash functions and ECDSA authentication. Again, the correct algorithms, key stores, signing tools and recovery behaviour come from the exact device and Quartus release, not from the QSPI part number.

The security design should answer four separate questions:

• Authenticity: who signed this image, and which public-key hash or root key is fused into the device?
• Integrity: will any unauthorized modification stop the image before logic or software is released?
• Confidentiality: must the external image be encrypted to prevent cloning or reverse engineering?
• Freshness and recovery: how is an old but valid image rejected, and how can the product recover when the newest image is corrupt or power is interrupted?

Authentication without a tested recovery image can create a secure brick. Encryption without controlled key generation, storage and revocation can create an unrecoverable manufacturing problem. The production release packet should name the signing tool version, key identifier, image hash, security-fuse state, allowed rollback floor and recovery procedure without exposing secret material.

Current memory examples and their real boundaries #

The models below illustrate voltage, package, lifecycle and managed-NAND boundaries. They are not a claim that every model appears in every FPGA vendor's supported-flash list. Manufacturer pages and documentation were checked on August 21, 2026; the exact FPGA and tool release must still approve the device.

The 512 Mbit NOR examples hold 64 Mbytes, not 512 Mbytes. Density-unit mistakes become expensive when a team reserves primary, golden and field-update slots. Build a flash map in bytes, include erase-block alignment and preserve unused space for future signed-image growth.

Validate the failure paths, not only the golden boot #

A board that boots once through JTAG has not qualified its configuration system. Release testing should include:

For remote update, test every transition that changes the authoritative image pointer. Agilex RSU, AMD MultiBoot and Versal fallback are family-specific mechanisms; do not reduce them to a generic A/B partition diagram. The factory image should be small, protected and capable of receiving or selecting a valid update. A recovery image that shares the same untested driver or corrupted metadata as the application image is not independent recovery.

Freeze the BOM and the security process together #

An RFQ for “512 Mb QSPI flash” leaves the highest-risk decisions open. Provide:

• the full manufacturer part number, voltage, package, temperature grade and packing code;
• the exact FPGA/SoC OPN, boot mode and I/O rail;
• the approved Vivado or Quartus release and supported-memory selection;
• required density after primary, factory and update images are allocated;
• boot-clock/read-command requirements, address mode and reset-pin use;
• lifecycle, change-notification and lot-traceability requirements;
• whether an alternate requires reprogramming-fixture, secure-boot, power-loss and environmental requalification.

Engineering should also archive the generated programming file, flash map, boot-mode straps, security policy and test results. Purchasing can then compare available devices against a controlled interface rather than trying to infer compatibility from density and package alone.

Conclusion #

QSPI NOR remains the normal direct-configuration memory because an FPGA or its SDM can read a supported bitstream immediately after reset. eMMC is appropriate only when a processor-equipped FPGA or adaptive SoC explicitly provides a processor-managed boot path. Secure boot sits above both: the device root of trust authenticates, and optionally decrypts, the image before logic or software is released.

The defensible BOM therefore locks four things together—the FPGA generation, boot topology, exact memory OPN and security/recovery process. If any one changes, repeat the affected programming, timing, authentication and interrupted-update tests before approving the substitute.

Official references #

• AMD UltraScale Architecture Configuration User Guide UG570, revision 1.20.1
• AMD UG570 Master SPI interface and supported bus widths
• AMD UG570 bitstream encryption and authentication guidance
• AMD Versal System Software Developers Guide UG1304: boot-device modes, 2026.1
• AMD Versal UG1304 secure-boot flow, 2026.1
• AMD Vivado Programming and Debugging UG908: adding a configuration-memory device, 2026.1
• Altera Agilex 5 Device Configuration User Guide: configuration architecture
• Altera Agilex 5 active-serial configuration hardware and QSPI guidance
• Altera Agilex 5 SoC device overview: HPS eMMC and SDM security features
• Altera Agilex 7 SoC Boot User Guide: SDM QSPI ownership
• Micron current serial-NOR part catalogue
• Infineon S25HL512TDPNHV010 product page and lifecycle position
• Kingston commercial and industrial eMMC product table