Partial reconfiguration (PR) is the ability to reprogram a defined region of an FPGA's programmable fabric while the rest of the device continues to operate normally. Only the bitstream for the targeted region is loaded, leaving unaffected logic running without interruption.
In practice
Partial reconfiguration is supported on mid- to high-end FPGAs from Xilinx (Vivado PR flow, available on 7-series, UltraScale, and UltraScale+) and Intel/Altera (Partial Reconfiguration flow on Cyclone V, Arria, and Stratix families). Lattice offers partial reconfiguration capability on select ECP5 and Avant devices, though tool support, terminology, and flow maturity differ from Xilinx and Intel implementations. It is not universally available; small, low-cost FPGAs often lack the infrastructure required to isolate and reload individual regions safely.
In practice, PR is used when a single FPGA must perform multiple distinct functions that do not all need to run simultaneously -- for example, cycling through different DSP kernels, protocol bridges, or compression engines without taking the entire device offline. It is also used to reduce bitstream transfer time when only a small portion of the design changes between operational modes, which matters in systems where reconfiguration latency is a hard constraint.
A key design discipline is defining clean "reconfigurable partition" boundaries (called reconfigurable modules or dynamic function exchange regions, depending on the vendor toolchain). Logic signals crossing the boundary must go through dedicated interface elements -- decoupler logic in Xilinx flows, or equivalent isolation cells -- to prevent glitching on static logic while the partial bitstream loads. Violating this boundary discipline is the most common source of system instability during PR.
Partial bitstreams are typically generated offline by the vendor toolchain and stored in NOR flash, SD card, or host memory, then streamed to the FPGA via ICAP (Xilinx internal configuration access port), PCIe, or an external configuration controller. Managing multiple partial bitstream versions, verifying their compatibility with the static region build, and handling reconfiguration errors (corrupted bitstream, wrong version) are practical firmware engineering concerns that add significant complexity compared to full-device reconfiguration.
Discussed on FPGARelated
Frequently asked
Does the rest of the FPGA actually keep running during partial reconfiguration?
On devices that support PR, the static region continues to operate during loading of the partial
bitstream. However, any logic in the reconfigurable region is in an undefined state during the transition, and outputs crossing the partition boundary must be held to safe values using decoupler or isolation logic. Failure to do so can corrupt state in the static region.
What is a partial bitstream and how does it differ from a full configuration bitstream?
A full
bitstream programs every configuration frame in the
FPGA. A partial bitstream targets the configuration frames that correspond to the reconfigurable region; in practice it may include additional framing overhead or touch adjacent frames due to FPGA frame granularity, but the bulk of the data is specific to that region. It is generated by the vendor toolchain alongside the full bitstream at implementation time. The two must be built together from the same static design; a partial bitstream from one build is generally not compatible with the static region from a different build.
What is ICAP and why does it appear in PR designs?
ICAP (Internal Configuration Access Port) is an on-chip interface present on many Xilinx FPGAs that provides fabric logic with access to the device's internal configuration logic. In PR designs, a soft controller instantiated in the static region can read a partial
bitstream from storage and feed it through ICAP without requiring an external configuration master. Intel FPGAs support self-managed partial reconfiguration through vendor-provided PR IP cores, though the architecture and interface differ from Xilinx's ICAP.
How is partial reconfiguration different from just using a multiplexer to switch between functional blocks?
A multiplexer approach keeps all logic implemented simultaneously and simply selects which path is active; all resources are consumed at once. Partial reconfiguration physically replaces the logic in a region with different logic, so the
FPGA resources for modes not currently in use are freed. This is the primary advantage: resource reuse across time rather than resource duplication.
Is partial reconfiguration difficult to implement?
Yes, by
FPGA development standards it is one of the more complex flows. It requires floorplanning the reconfigurable regions, managing partition interfaces, generating and versioning multiple partial bitstreams, and implementing safe reconfiguration sequencing in firmware. Vendor tools have improved significantly (Xilinx's Dynamic Function eXchange flow in
Vivado, Intel's PR flow in Quartus), but the discipline of keeping partition boundaries clean and
bitstream versions consistent adds meaningful engineering overhead compared to a static design.
Differentiators vs similar concepts
Partial reconfiguration is sometimes conflated with full reconfiguration (loading a complete new
bitstream) or with run-time configuration of soft-core parameters. Full reconfiguration resets and reprograms the entire device, interrupting all running logic. Partial reconfiguration reprograms only a designated region while the rest of the device stays live. It is also distinct from configuration scrubbing, which periodically reads configuration memory and corrects bit errors caused by single-event upsets without changing functionality.
