Platform Support for Segmented Configuration Flow - 2025.2 English

A Segmented Configuration build flow in Vivado generates the configuration bitstream as two images:

A boot.pdi image that boots the processing system, DDR/LPDDR memory controllers, and NoC paths between them.
A pl.pdi image that can be loaded after the boot.pdi. The pl.pdi represents the design content not contained within the boot.pdi image, which can be loaded after the boot.pdi.

The pl.pdi image can be reloaded multiple times while the processing system and DDR remain active. The Vitis Integrated flow, VMA Export, and VSS generation flows all support Segmented Configuration.

Details on the Segmented Configuration feature and steps to enable it in Vivado designs can be found in the Segmented Configuration Design Tutorial.

Deferred Load Flow

The deferred load flow defers PL/AIE configuration (pl.pdi/pl_aie.pdi) until after a fast OS boot using boot.pdi. This prioritizes essential components (CIPS/PSXC, NoC, DDRMCs) for quicker startup. This separation facilitates a fast OS boot, while deferring the full PL (or PL and AIE) configuration until it is needed.

Dynamic Load / Reload Flow

The dynamic load / reload flow enables dynamic, on-the-fly PL reconfiguration (using pl.pdi) by separating the Processing System (PS) and Operating System (OS) boot process (using boot.pdi) from the rest of the device configuration. This offers similar capabilities to DFX but with simplified implementation. The pl.pdi acts as a reconfigurable module, encompassing all design elements except CIPS, NoC, and DDRMCs.

A key aspect of this approach is managing activity within the processing domain during a reload. While automatic isolation is enabled and disabled at the PS-PL boundary, you are responsible for managing activity within the processing domain during the transition, including pausing activity and unloading and reloading drivers as needed. Furthermore, the segmented configuration supports multiple pl.pdi, enabling the creation of several PL configurations that are compatible at both boot and runtime with a single boot.pdi. This allows for flexible and dynamic reconfiguration of the PL without requiring a full system reboot or changes to the boot image.

Benefits and Implementation

The primary benefits of Segmented Configuration include a smaller boot image required to bring up the processor and OS. Another benefit is the ability to enable runtime PL reconfigurability without the complexity of a full DFX build flow.

The PL PDI can be loaded on primary or secondary boot paths without PL dependency, using PCIe endpoints via CPM or from remote storage or boot devices.

Platform and Deferred Load of PL (and AIE) Image

The process of generating and using an extensible XSA tailored for deferred flow in the Vivado and Vitis environments involves the following steps.

Vivado:

In Vivado, the flow begins by configuring the project for segmented configuration using the command:

set_property segmented_configuration [current_project]

Important: This property is always enabled for all Versal AI Edge Series Gen2 device based designs. This property is optional and turned off by default for first-generation Versal adaptive SoCs.

This property is followed by setting the PFM properties as per design requirements and executing generate_target all to prepare the design. At this stage, the design remains in its pre-synthesis phase, meaning it has not yet been implemented within Vivado. The write_hw_platform command then generates the extensible.xsa file using write_hw_platform –hw extensible.xsa, which serves as the hardware platform definition.

The Tcl script snippet of the steps is shown below:

generate_target all [get_files vck190sc.bd]

set_property platform.extensible true [current_project]
set_property platform.platform_state "pre_synth" [current_project]
set_property platform.design_intent.embedded "true" [current_project]
set_property platform.design_intent.server_managed "false" [current_project]
set_property platform.design_intent.external_host "false" [current_project]
set_property platform.design_intent.datacenter "false" [current_project]
set_property platform.run.steps.place_design.tcl.pre [get_files prohibit_select_bli_bels_for_hold.tcl]
update_compile_order -fileset sources_1
save_bd_design

# deferred load
write_hw_platform -force ./vck190sc-deferred.xsa

Vitis:

This extensible.xsa can be used in both the Vitis Integrated Flow and Vitis Export to Vivado Flow. In the Vitis integrated flow, v++ --link creates a fixed XSA containing the boot.pdi and pl.pdi files which can be packaged with the AIE content using the v++ package flow.

In the Vitis Export to Vivado flow, the VMA is exported to Vivado, and the Vivado project can then be implemented according to specific requirements of the project to generate the final boot.pdi and pl.pdi files.

This deferred approach allows for a separation of concerns, enabling hardware platform definition before full implementation.

Platform and Dynamic Load/Reload of PL (and AIE) Image

Vivado

In Vivado, the flow begins by configuring the project for segmented configuration using the command:

set_property segmented_configuration [current_project]

This is followed by setting the PFM properties as per the design requirements and implementing the design. Use the write_hw_platform command to generate the extensible.xsa. When you run this command, it automatically checks if segmented configuration property is enabled. If enabled, the generated extensible XSA file will contain the routed design checkpoint (DCP) and the NoC configuration, including the necessary boot paths. This ensures everything required for dynamic reload of the PL(and AIE) is included in the XSA.

The Tcl script snippet of the steps is shown below.

generate_target all [get_files vck190sc.bd]

set_property platform.extensible true [current_project]
set_property platform.platform_state "pre_synth" [current_project]
set_property platform.design_intent.embedded "true" [current_project]
set_property platform.design_intent.server_managed "false" [current_project]
set_property platform.design_intent.external_host "false" [current_project]
set_property platform.design_intent.datacenter "false" [current_project]
set_property platform.run.steps.place_design.tcl.pre [get_files prohibit_select_bli_bels_for_hold.tcl]
update_compile_order -fileset sources_1
save_bd_design

# deferred load
write_hw_platform -force ./vck190sc-deferred.xsa

if { [lindex $argv 0] == "dynamic_reload" } {
  update_compile_order -fileset sources_1
  launch_runs impl_1 -to_step write_device_image -jobs 5
  wait_on_run impl_1
  if {{get_property PROGRESS [get_runs impl_1]} != "100%"} {
    error "ERROR: Implementation failed"
  }
  open_run impl_1
}

#dynamic reload
write_hw_platform -hw -force vck190sc.xsa

Vitis

This extensible.xsa can be used in both the Vitis integrated flow and Vitis export to Vivado flow. In the Vitis integrated flow, v++ --link creates a fixed XSA containing the boot.pdi and pl.pdi files which can be packaged with the AIE content using the v++ package flow.

In the Vitis export to Vivado flow, the VMA is exported to Vivado, and the Vivado project must then be implemented according to specific requirements of the project to generate the final boot.pdi and pl.pdi files. Adherence to Vivado's segmented configuration requirements for dynamic reload is crucial to ensure proper functionality. This approach allows for dynamic updates to the PL without requiring a full system reboot.

Packaging the AIE

A fixed XSA generated by the v++ linker or by Vivado in the VMA Export flow contains a pl.pdi but not an AI Engine .pdi containing core ELF and configuration data objects (.cdo). The v++ package tool extracts the AI Engine image data from compiled libadf.a, archives and merges it with the PL content in a fixed XSA to create image files to load onto the target device. The package command generates several output files, including pl_aie.pdi, pl_aie.dtbo, and pl_aie.xclbin. The command used to package these files is:

v++ -p -s -f <fixed>.xsa
				libadf.a --package.out_dir <package directory> -o <xclbin_name>.xclbin

The package command generates a merged pl_aie.pdi and pl_aie.xclbin file that can be loaded by the xrt::loadXclbin() API. The Linux OS requires a pl_aie.dtbo device tree overlay to configure PL drivers, which can be loaded with the pl_aie.pdi using the fpgautil utility. Because the pl_aie.pdi image is loaded by fpgautil, the xrt::loadXclbin() invocation by the software application loads only design metadata used by XRT.