--- title: "What an Interchangeable FPGA Function Must Match" description: "Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21." canonical: "https://www.leviathansystems.co/articles/fpga-dfx-static-partition-module-compatibility" last-updated: "2026-10-21" --- # What an Interchangeable FPGA Function Must Match Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21. An interchangeable FPGA function needs an implementation supported for the delivered static design, the intended reconfigurable partition and its interface, plus the software-visible hardware context required by that platform. The FPGA part and function name alone do not establish that relationship. Establish which alternatives the appointed hardware and software providers support in that context, then assess the application's required behavior separately. ## Identify the hardware that stays and the hardware that changes AMD's Dynamic Function eXchange, or DFX, allows part of an FPGA design to change while the static design remains in place. In UG909 2025.2, the static design comprises static logic and routing. A reconfigurable partition, or RP, defines where alternative reconfigurable modules, or RMs, are implemented. A complete configuration has one RM for each RP. For a buyer, the useful identity is therefore more specific than an FPGA device and a preprocessing function. It includes the retained static design, the selected partition and the implementation supplied for it. A function describes the work wanted; those design relationships establish where its hardware implementation belongs. References: [T1](https://docs.amd.com/r/2025.2-English/ug909-vivado-partial-reconfiguration/Terminology) ## A matching interface includes physical connections The interchangeable hardware must connect to hardware that is retained. AMD's Reconfigurable Partition Interfaces guidance in UG909 2025.2 requires consistent logical and physical connections between the static design and the alternative modules. It explains that the static side is locked after the initial configuration, limiting what later implementations can change. A familiar port name or a matching function label cannot establish that physical relationship. Ask the hardware provider to identify the actual partition interface and the supported implementations for it. This is why an interchangeable-function offer needs implementation-specific evidence, rather than an assurance that the FPGA is generally programmable. References: [RP](https://docs.amd.com/r/2025.2-English/ug909-vivado-partial-reconfiguration/Reconfigurable-Partition-Interfaces) ## DFX3: two supported alternatives occupy one partition Consider fictional delivery DFX3. Its static design S1 contains exactly one reconfigurable partition, P, with fixed interface I1. The supplier supports M_A and M_B as alternative implementations for S1/P/I1. M_A performs image resizing; M_B performs normalization. These labels and support relationships are teaching assumptions, with no actual equipment or measured result behind them. The offer contains two documented alternatives for P. Exactly one of those modules occupies P at a time in this example. Selecting M_B changes the function implemented there; it does not add a second accelerator alongside M_A. If the buyer needs resizing and normalization together, the two-file offer has not established that combined behavior. The responsible design provider must explain a supported implementation that meets the combined requirement. Nor does possession of both files establish an automatic sequence that preserves intermediate data between them. Counting available alternatives answers a selection question; it does not answer a concurrent-capacity or complete-pipeline question. ## A third function needs evidence for S1/P/I1 The buyer now requests color conversion. The supplier returns M_C, bearing that function name and the same FPGA part as the delivered equipment. Its accompanying implementation record identifies static design S2 and interface I2. Nothing supplied connects it to S1/P/I1. The initial finding is unresolved applicability. The record does not justify counting M_C as a third supported alternative for S1, but it also supplies no failed compatibility test or proof that the requested function cannot be implemented there. Ask the appointed hardware provider for an implementation explicitly supported in S1/P/I1, with the applicable relationship to the platform's software-visible hardware description and dependencies identified by the responsible software provider. Merely renaming M_C or repeating the device part does not resolve the missing relationship. Suppose the provider subsequently supplies M_C1 and establishes that support for S1/P/I1, together with the required software context. Under this new fictional premise, the documented set grows from two to three alternatives. P still contains one selected module at a time. No actual loading, execution or application acceptance has occurred in this example. If the provider instead proposes replacing S1, evaluate that as a changed design with changed dependencies. ## A static-design change changes the reuse question AMD's Static Design Updates passage in UG909 2026.1 explains that implementation results are produced in their top-down design context. Updating static hardware requires reimplementation of the RM results dependent on that hardware. Its nested-design example also distinguishes affected descendants from unaffected branches. In DFX3, replacing the actual static hardware S1 with S2 therefore calls for renewed applicability evidence for M_A, M_B and any other dependent implementation. Their earlier S1 support cannot establish S2 support merely because the FPGA part is unchanged. Identify what actually changed. A new software release label does not by itself mean that static logic or routing changed. Conversely, an unchanged equipment model does not demonstrate an unchanged static implementation. Have the appointed design provider identify the retained design revision, affected modules and supported replacements where needed. This comparison uses UG909 2025.2 for interfaces and terminology, and 2026.1 for the static-update dependency passage. References: [SU](https://docs.amd.com/r/en-US/ug909-vivado-partial-reconfiguration/Static-Design-Updates) ## Connect the hardware binary to the software's view AMD EDF Documentation 26.06.1-rev1 adds a useful system-level distinction for its Adaptive SoC context. It defines a module using both a hardware binary and a hardware description interpretable by software, specifically device tree. It identifies the system-level design as the primary source for deciding which hardware belongs to that module. For a purchase using that platform context, a hardware file alone leaves part of the described delivery unresolved. Ask the responsible providers to connect the selected implementation to its actual software-visible hardware membership and dependencies. Other FPGA platforms need their own documented delivery model; the named AMD formats and device-tree flow are not universal requirements. The same EDF page treats segmented configuration and DFX as separate use cases and warns that hardware and software interaction needs care. A proposal should identify its actual flow instead of treating any later hardware loading as evidence of interchangeable DFX functions. References: [ED](https://edf.docs.amd.com/en/v26.06.1/seg/segmented-configuration-or-dynamic-function-exchange.html) ## Buy a supported alternative and define the result still needed For the fixed S1 deployment, retain a delivery package that connects the equipment identity to S1, P, I1 and each supported alternative implementation. Include the applicable software description and dependency identities, the provider's support statement and the evidence it returns for those relationships. That lets a later reviewer distinguish an applicable alternative from an unrelated implementation with the right function name. For a planned design refresh, establish who will supply revised implementations and the associated software context. Identify the retained design inputs or the supported regeneration route that party will use. A directory of old partial hardware files leaves the future-change responsibility unanswered. Supported applicability and application acceptance are separate decisions. Retaining static hardware does not establish preservation of module state, completion of in-flight requests, uninterrupted application service, or any power, timing or throughput result. Have the appointed hardware and software teams address the behavior the application owner actually requires, with agreed evidence for the selected configuration. For a buyer who only needs one fixed function, the supported S1 alternative may be the appropriate purchase. For one who expects function changes or a static-design refresh, the useful extra deliverable is a supported path through that change, with its responsible provider identified. ## Carry the selected complete equipment into a physical project If the selected equipment also needs a separately agreed rack installation, Leviathan's rack-and-stack service covers agreed equipment mounting, physical IT cabling, labels and installation records. The service and project inquiry below provide the next step for that physical scope. Share a nonconfidential equipment summary, appointed supplier, released rack and external connection plans, site requirements and required handoff. FPGA design, implementation generation, hardware loading, software integration and application validation remain with the appointed technical providers. This article supports an equipment-selection decision; it supplies no build, loading or field procedure and no work approval. References: [L1](https://www.leviathansystems.co/services/rack-and-stack) ## Primary sources - [T1 — AMD UG909 2025.2: Terminology](https://docs.amd.com/r/2025.2-English/ug909-vivado-partial-reconfiguration/Terminology). Checked 2026-10-21. December 17, 2025 edition: configuration, RP, RM and retained static logic/routing definitions. - [RP — AMD UG909 2025.2: Reconfigurable Partition Interfaces](https://docs.amd.com/r/2025.2-English/ug909-vivado-partial-reconfiguration/Reconfigurable-Partition-Interfaces). Checked 2026-10-21. December 17, 2025 edition: logical and physical interface consistency between alternative modules. - [SU — AMD UG909 2026.1: Static Design Updates](https://docs.amd.com/r/en-US/ug909-vivado-partial-reconfiguration/Static-Design-Updates). Checked 2026-10-21. July 1, 2026 edition: top-down implementation dependencies, including affected descendants in nested DFX. - [ED — AMD EDF Documentation 26.06.1-rev1: Segmented Configuration or Dynamic Function eXchange](https://edf.docs.amd.com/en/v26.06.1/seg/segmented-configuration-or-dynamic-function-exchange.html). Checked 2026-10-21. Adaptive SoC module definition, system-level hardware membership and hardware/software interaction; platform-specific delivery scope. - [L1 — Leviathan Systems: Rack-and-Stack and Colocation Installation](https://www.leviathansystems.co/services/rack-and-stack). Checked 2026-10-21. Physical equipment mounting, agreed IT cabling, labels and installation records for a separately scoped project. ## Related Leviathan resources - [ONNX graphs, TensorRT engines and software-artifact reuse](/articles/onnx-model-versus-tensorrt-engine-portability) - [Delivered firmware and the version actually in use](/articles/gpu-firmware-staged-versus-active-version) - [Rack-and-stack installation for selected complete equipment](/services/rack-and-stack) - [Discuss a separately needed physical installation](/contact?service=rack-and-stack&from=%2Farticles%2Ffpga-dfx-static-partition-module-compatibility) - [Activation Checkpointing: Recompute Intermediates, Preserve Recovery Separately](/articles/activation-checkpointing-recompute-versus-training-recovery) ## Does the selected equipment need rack installation? Share a nonconfidential equipment summary, released rack and external connection plans, site requirements and physical handoff needs to discuss scope and availability. [Discuss the scope](/contact?service=rack-and-stack&from=/articles/fpga-dfx-static-partition-module-compatibility)