Segmented Configuration or Dynamic Function eXchange

Segmented Configuration or Dynamic Function eXchange

 

Whether you are using the AMD Embedded Development Framework (EDF) or making your own software, many users need the ability to reconfigure portions of the hardware without re-starting the software.

When using this functionality on AMD's Adaptive SoCs there are a number of steps you must take in order to ensure that the software and hardware interact smoothly and do not cause crashes or un-defined behavior.

Table of Contents

Generic vs AMD tooling approach

This page contains the general steps users will need to take in order to use Segmented Configuration or Dynamic Function eXchange.

If you are using AMD’s Yocto Project tooling, take a look at the DFX (Green in the below diagram) or Segmented Configuration (Blue in the below diagram) pages.

 

dfx_segmented_options.png

 

 

Definitions

  • “Module”: A grouping of hardware that can be loaded as a unit, represented by a binary file that represents the machine interpretable hardware (.bin for AMD Zynq™ UltraScale+™ MPSoC devices, or .pdi for the AMD Versal™ portfolio), and a hardware description that is interpretable by the software (device tree). Modules are intended to be loaded/enabled/reconfigured at an arbitrary time, by firmware, by bootloaders, by hypervisors or by individual operating systems.

  • “Segmented configuration”: Only applies to Versal and later devices (although Zynq MPSoC has a similar concept referred to as “classic SoC boot”). “Segmented configuration” is when a subset of the total hardware in the system (usually just enough to boot the software), is separate from the rest of the hardware in the system and the software uses special drivers or commands (fpgamanager or dfxutil in the case of Linux) to load the rest of the hardware.

Steps

  1. Identify hardware that is in the module to be loaded after boot. Hardware design tools might be able to help you identify this information, but your system level design is the primary source of this information.

  2. Isolate the identified hardware to its own device tree file (.dtsi)

    1. AMD has two use cases for reconfiguration: Segmented Configuration and Dynamic Function eXchange (DFX).

      1. For Segmented Configuration, AMD assumes that hardware in the pl.dtsi file produced by SDTGen correlates 1:1 with the data in the post-boot module.

  3. Modify (using lopper with the appropriate lops) the isolated hardware device tree to ensure it is enclosed in an appropriate block.

    1. The appropriate block is defined by the FPGA driver, the bindings for which are defined here. An example is going from:

      / { amba_pl: amba_pl { ranges; compatible = "simple-bus"; #address-cells = <2>; #size-cells = <2>; firmware-name = "zcu_104_demo_mpsoc_preset_wrapper.bit.bin"; clocking0: clocking0 { ...

      to

      /dts-v1/; /plugin/; &fpga_full{ firmware-name = "zcu_104_demo_mpsoc_preset_wrapper.bit.bin"; }; &amba{ clocking0: clocking0 { ...
  4. Remove the isolated hardware from the system device tree. In AMD software flows this is accomplished by removing pl.dtsi from system-top.dtsi.
    Old version:

    /dts-v1/; #include "zynqmp.dtsi" #include "zynqmp-clk-ccf.dtsi" #include "pl.dtsi" #include "pcw.dtsi" / { board = "zcu104"; device_id = "xczu7ev"; slrcount = <1>;

    New version:

    /dts-v1/; #include "zynqmp.dtsi" #include "zynqmp-clk-ccf.dtsi" #include "pcw.dtsi" / { board = "zcu104"; device_id = "xczu7ev"; slrcount = <1>;
  5. Compile the isolated hardware information into a device tree binary. (using the device tree complier)

  6. Obtain the FPGA binary file (.bin file for ZynqMP, or .pdi for Versal and later)

    1. If you have a .bit file (as opposed to a .bin file), use bootgen to remove the headers and sync words as those are not needed by fpgautil

  7. If using DFX (not Segmented Configuration) Create a shell.json

  8. Put the compiled .dtb file, the FPGA binary file, and shell.json onto your filesystem in /lib/firmware/xilinx.

  9. Run dfx-mgr pointing to /lib/firmware/xlinx.

Trademarks

Yocto Project and all related marks and logos are trademarks of The Linux Foundation. This website is not, in any way, endorsed by the Yocto Project or The Linux Foundation.

Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

© 2025 Advanced Micro Devices, Inc. Privacy Policy