How to Use Versal Segmented Configuration
Goal: Build a Versal design that emits both a base (static) PDI for BOOT.BIN
and a runtime-loadable (dynamic) PDI from a single RTL source, using Vivado’s
Segmented Configuration feature without requiring a Reconfigurable Partition wrapper
or a DFX license.
Note
Unlike Dynamic Function eXchange (DFX), Segmented Configuration does not require a Vivado DFX license. It does require Vivado 2025.1 or later. See How to Use Dynamic Function eXchange (Partial Reconfiguration) if you need an explicit Reconfigurable Partition wrapper instead.
Prerequisites
A Versal target part (the property is rejected on non-Versal architectures)
Vivado 2025.1 or later (Segmented Configuration is unsupported on earlier versions)
No DFX license required, and no Reconfigurable Partition / pblock floorplanning needed
No RTL changes required — the Vivado tool splits the design into boot and PL partitions automatically based on hard-block boundaries (PMC, PS, NoC, DDR controller into the boot PDI; everything else into the PL PDI)
When to Use
Use Segmented Configuration when you want runtime PL reload on a Versal target
through the Linux fpga_manager driver (fpgautil -b /boot/pl.pdi), but
without restructuring your RTL into Reconfigurable Partitions.
The Versal Platform Management Controller (PMC) requires the runtime-loaded PDI
to be distinct from the base PDI baked into BOOT.BIN. Segmented
Configuration provides that distinct runtime PDI as a build-time output of the
same RTL — see the AMD Solution Versal PL Programming
wiki for the underlying base-vs-runtime PDI model.
Opt-in
Set a single environment variable in your target Makefile before including
system_vivado.mk:
export USE_SEGMENTED_CONFIG = 1
include $(TOP_DIR)/submodules/ruckus/system_vivado.mk
When USE_SEGMENTED_CONFIG = 1, ruckus calls EnableSegmentedConfig
during properties.tcl (which sets SEGMENTED_CONFIGURATION 1 on the
project) and ExportSegmentedPdi during build.tcl (which renames the
two Vivado-emitted PDIs to the SLAC suffix convention below). The default value
is 0 (standard single-PDI Versal build — no behavior change).
Outputs
After a successful Segmented build, two PDI files appear in images/:
<Target>-<PRJ_VERSION>-<timestamp>-<user>-<sha>_static.pdi
<Target>-<PRJ_VERSION>-<timestamp>-<user>-<sha>_dynamic.pdi
The _static.pdi becomes base-design.pdi inside BOOT.BIN; the
_dynamic.pdi is the artifact loaded at runtime by fpgautil (typically
shipped to the Linux rootfs as /boot/pl.pdi).
Both names inherit the full SLAC <Target>-<PRJ_VERSION>-<timestamp>-<user>-<sha>
convention from $IMAGENAME — only the suffix differs.
Key Variables
Variable |
Default |
Description |
|---|---|---|
|
|
Enables Vivado 2025.1+ Segmented Configuration mode on Versal targets.
When set to |
See the Makefile Reference for the complete variable reference.
Limitations and Non-Goals
No no-reboot runtime reload helper. Segmented Configuration produces the artifact; how Linux loads it (boot-time via
startup-app-initvs runtime via a userspace helper) is the consumer’s concern.No multi-variant PL support. This hook handles the single-design two-PDI flow only. Designs that need multiple distinct PL PDIs sharing one boot PDI require
read_noc_solution/write_noc_solutionandpr_verifyinvocations not currently exposed by the hook.No DFX migration. If you need explicit Reconfigurable Partitions, decouplers, or floorplanning, see How to Use Dynamic Function eXchange (Partial Reconfiguration) — Segmented Configuration is the alternative to that flow, not a stepping stone toward it.
Troubleshooting
- “Versal Segmented Configuration requires Vivado 2025.1 or later”
Source a Vivado 2025.1+
settings64.shbefore runningmake. Older Vivado releases do not implement theSEGMENTED_CONFIGURATIONproject property and the build will abort. SLAC AFS users:source /sdf/group/faders/tools/xilinx/2025.2/Vivado/2025.2/settings64.sh.- “USE_SEGMENTED_CONFIG=1 ignored: target FPGA is not Versal”
The opt-in env var was set but the target’s
PRJ_PARTis a non-Versal architecture.EnableSegmentedConfigfalls through as a no-op so the build completes — but the two-PDI output will not appear. Either removeUSE_SEGMENTED_CONFIGfrom the target Makefile or change the target part.- “Expected exactly one *_boot.pdi in IMPL_DIR” (or
*_pld.pdi) Vivado did not emit the segmented PDIs even though the property was set. Check
runme.login the impl_1 run directory forSEGMENTED_CONFIGURATIONconfirmation; if absent, Vivado may have rejected the property silently for the part. If two-plus matches, clean the build directory (make distcleanor removevivadoProject*/) and rebuild.