Electronics Design AUWhy Won't My FPGA's DONE Pin Go High After Configuration?
Last updated 4 August 2026 · 5 min read
Direct Answer
An FPGA's DONE pin that never goes high after power-up almost always traces back to one of three causes: the mode pins are strapped to select a configuration source (JTAG, SPI flash, BPI) that doesn't actually have a valid bitstream on it, the configuration data itself is corrupt or doesn't match the target device, or a supply rail relevant to the configuration logic hasn't reached a valid level before configuration starts. Reading the INIT_B pin's behaviour during power-up narrows down which of these it is before reaching for a bitstream rebuild.
Detailed Explanation
Every FPGA configuration cycle follows the same broad sequence regardless of vendor: the device clears its internal configuration memory, signals readiness, loads a bitstream from whichever source its mode pins select, and, if that bitstream loads successfully and passes its integrity checks, releases its internal logic to start running and asserts the DONE pin. A DONE pin that never goes high means the process stopped somewhere in that sequence, and the two other configuration-status pins, INIT_B and PROGRAM_B, tell you roughly where.
This page covers the mode-pin and configuration-pin bring-up sequence itself. For the higher-level FPGA build flow that produces the bitstream in the first place, see the FPGA development flow; for board-level supply sequencing that this troubleshooting connects to, see multi-rail power sequencing design.
Mode Pins and Boot Source Selection
The mode pins (commonly labelled M0–M2 or similar, the exact naming and pin count vary by vendor and family) are strapped to fixed logic levels on the board, typically with pull-up or pull-down resistors, to tell the FPGA at power-up which configuration source to load from: JTAG only, a Quad-SPI or SPI flash device, a parallel BPI flash, or (on newer families) a processor-driven configuration path. This strapping is a board-design decision made before layout, not something firmware changes at runtime, and it's the first thing to verify on a board that has never successfully configured: a mode-pin strapping error selects a configuration source with no valid bitstream present, or a source not physically connected the way the design assumes, which the FPGA correctly reports as a configuration failure because, from its perspective, nothing valid loaded.
Checking mode-pin strapping against the schematic and the specific values the target device's datasheet or configuration user guide defines for the intended boot source is a fast, purely electrical check that rules out an entire class of failure before touching the bitstream at all.
Reading INIT_B and PROGRAM_B
PROGRAM_B is an active-low input that forces the FPGA to restart its configuration sequence from the beginning; pulsing it low and releasing it is the standard way to force a reconfiguration attempt without a full power cycle.
INIT_B is bidirectional on most families: the FPGA drives it low briefly at the start of configuration while clearing its internal memory, then releases it (typically pulled high externally) once ready to receive configuration data. The FPGA can also drive INIT_B low again if it detects a CRC error or a device-ID mismatch during configuration, which makes its behaviour diagnostically useful:
- INIT_B stays low indefinitely, or pulses low repeatedly: configuration is failing at or shortly after the initialisation stage. Common causes are a CRC error in the bitstream, a bitstream built for the wrong device (a device-ID mismatch), or the configuration source itself being unreadable (a flash device with no valid image, or a JTAG connection with no data being clocked in).
- INIT_B looks normal (goes low briefly, then high), but DONE never asserts: the failure is later in the sequence, closer to the end of a genuinely-loading bitstream. This points toward a truncated or partially-corrupt bitstream, a configuration clock or data-rate issue on an externally-clocked configuration mode, or, on a multi-device daisy chain, a fault in a downstream device breaking the chain before it reaches the device whose DONE you're watching.
Verifying the Bitstream and Configuration Source Independently
Once mode-pin strapping and the INIT_B behaviour have narrowed the failure to "before DONE" versus "bitstream integrity," the next step is isolating the bitstream from the board. Configuring the same device over JTAG directly from the toolchain (bypassing whatever flash or BPI source the board's mode pins otherwise select) tests whether a known-good bitstream configures successfully on this specific board. If JTAG configuration succeeds but the board's normal boot source doesn't, the bitstream itself is very likely fine and the problem is specific to that configuration path: a flash programming issue, a wiring fault on that specific interface, or (returning to the earlier point) a mode-pin strapping mismatch with what's actually connected.
Design Considerations
- Verify mode-pin strapping against the datasheet before first power-up on a new board, rather than assuming a copied reference design's strapping applies unchanged to a different configuration source choice.
- Confirm configuration-relevant power rails reach valid levels before configuration begins. See multi-rail power sequencing design for the sequencing requirements FPGAs commonly impose between core, auxiliary, and I/O bank rails, since a rail still ramping when configuration starts can cause exactly this kind of failure.
- Use JTAG configuration to isolate a bitstream-vs-board-path failure early in bring-up. A bitstream that configures cleanly over JTAG but not from the board's normal boot source narrows the problem to that specific configuration path rather than the design as a whole.
- FPGA board bring-up and configuration debugging: Zeus Design's embedded team debugs FPGA configuration, power sequencing, and board bring-up issues as part of digital hardware and firmware development.
Common Mistakes
- Rebuilding and re-flashing the bitstream repeatedly in response to a DONE failure without first checking mode-pin strapping or INIT_B behaviour, which often points directly at the actual cause.
- Assuming a reference design's mode-pin strapping applies unchanged after switching the intended configuration source (for example, moving from SPI flash to a processor-driven boot path) without updating the strapping to match.
- Not checking power rail sequencing on a new board design before assuming a configuration failure is purely a bitstream or connectivity problem.
- Ignoring a downstream device's configuration failure on a multi-FPGA daisy chain, which can prevent DONE from asserting on devices earlier in the chain even when their own configuration data loaded correctly.
Frequently Asked Questions
- What's the difference between INIT_B and DONE for diagnosing a configuration failure?
- INIT_B and DONE indicate different stages of the same process. INIT_B goes low briefly at the start of configuration (as the FPGA clears its internal configuration memory) and should return high once the device is ready to receive configuration data; if it stays low or pulses repeatedly, configuration is failing at or before the data-loading stage, commonly a CRC error or a device-ID mismatch between the bitstream and the actual part. DONE only asserts after the entire bitstream has loaded successfully and the FPGA has started up its internal logic; if INIT_B looks normal but DONE never asserts, the failure is later in the process, more often a truncated bitstream, a timing issue in the configuration clock, or (on multi-FPGA daisy-chain configurations) an issue with a downstream device in the chain.
- Can incorrect power sequencing alone prevent DONE from asserting, even with a correct bitstream?
- Yes. If a rail the configuration logic depends on (commonly VCCO for the configuration bank, or the core voltage on some families) hasn't reached a valid level by the time configuration begins, the FPGA can fail to configure correctly regardless of how correct the bitstream itself is. This is why power sequencing and configuration troubleshooting need to be checked together rather than assumed independent, especially on a new board design where sequencing hasn't yet been validated in hardware.
References
Related Questions
FPGA Development Flow: From HDL to Working Hardware
Learn the complete FPGA development flow: synthesis, place-and-route, timing constraints, timing closure, and bitstream generation in Vivado and Quartus.
How Do You Design Power Sequencing for a Multi-Rail Board?
Design correct power-up sequencing for boards with multiple supply rails — sequencer ICs, RC-delay enable chains, power-good daisy chaining, and shutdown order.
How Do You Choose the Right FPGA Family?
How to choose an FPGA family: compare Xilinx Artix-7, Lattice ECP5 and iCE40, and Intel Cyclone on LUT count, toolchain, power, cost, and dev board ecosystem.
How Do You Use Zynq / SoC-FPGA Devices?
How Zynq and other SoC-FPGA devices integrate a hard ARM processor with FPGA fabric: PS-PL AXI interconnect, boot flow, and PetaLinux vs bare-metal.
How Do You Protect an FPGA Bitstream With Encryption and Anti-Tamper Features?
An unencrypted FPGA bitstream in external flash can be copied wholesale. Bitstream encryption and anti-tamper features protect the design IP inside it.
How Do You Debug Embedded Firmware?
Covers JTAG/SWD hardware debugging, printf over UART or SWO trace, and logic analyser use for embedded firmware on STM32, ESP32, and other MCU platforms.