Overview of IDF+DFX

Isolation Design Flow for Zynq UltraScale+ MPSoCs and UltraScale+ FPGAs (XAPP1335)

Document ID
XAPP1335
Release Date
2023-05-15
Revision
2.2 English

The Isolation Design Flow (IDF) and Dynamic Function eXchange (DFX) are two production solutions from AMD. They have been available for Zynq UltraScale+ devices from Vivado 2018.3 onwards. From Vivado 2020.2 onwards, AMD supports combined flow of IDF and DFX. The document is written with the assumption that the reader is familiar with both IDF and DFX methodologies. For details on these individual methodologies, refer to Isolation Design Flow in this application note, Vivado Isolation Verifier User Guide (UG1291), Isolation Design Example for Zynq Ultrascale+ MPSoC Application Note (XAPP1336), Vivado Design Suite User Guide: Dynamic Function eXchange (UG909), and Vivado Design Suite Tutorial: Dynamic Function eXchange (UG947). With this combined support, the user can create nested isolated modules (IM) inside reconfigurable partition (RP). Sample design hierarchy structure looks like the following example provided here.

Figure 1. IDF+DFX Design Hierarchy

These isolated and reconfigurable regions require a floorplan that defines the overall usage of the device. An example floorplan might look like this:

Figure 2. Example Floorplan for IDF+DFX Design

The reconfigurable partition can have one or more reconfigurable modules that will be dynamically exchanged by way of partial bitstream delivery, most likely via the processing system (PS). Users must develop their own solution for delivering partial bitstreams and handling any runtime tasks (logical decoupling of the dynamic region, updates to drivers associated with reconfigured peripherals).

AMD supports isolation design flow (IDF) with one or more reconfigurable partitions (RP). Users can have one or more isolated modules (IM) inside the RP region or outside the RP region (in Static region). The support for change of composition (hierarchy, floorplan) of the nested IMs inside the RP from one reconfigurable module (RM) to the next is limited. It is strongly recommended to keep the same floorplan for each configuration. The complete support for this will be added in future Vivado releases.

Use cases that are NOT supported include:

  • Nesting an isolated region within an isolated region
  • Nesting a reconfigurable partition within an isolated region
  • Nesting of a reconfigurable partition within a reconfigurable partition and then an isolated partition under that.
  • Identifying a single module as both reconfigurable and isolated

This last exception can be effectively supported by directly instantiating a level of hierarchy such that an isolated module is directly below a reconfigurable partition and their floorplans are identical.