Dynamic Function eXchange Design Checklist (7 Series) - 2023.2 English

Vivado Design Suite User Guide: Dynamic Function eXchange (UG909)

Document ID
Release Date
2023.2 English

AMD highly encourages the following items for a 7 series FPGA design using Dynamic Function eXchange:

Recommended Clocking Networks

Are you using global clock buffers, regional clock buffers, or clock modifying blocks (MMCM, PLL)?

These blocks must be in static logic.

See Design Elements Inside Reconfigurable Modules for more information, and Global Clocking Rules for complete details on global clock implementation.

Configuration Feature Blocks

Are you using device feature blocks (BSCAN, CAPTURE, DCIRESET, FRAME_ECC, ICAP, STARTUP, USR_ACCESS)?

These featured blocks must be in static logic.

See Design Elements Inside Reconfigurable Modules for more information.

High Speed Transceiver Blocks

Do you have high speed transceivers in your design?

High speed transceivers must remain in the static partition.

See Using High Speed Transceivers for specific requirements.

System Generator DSP Cores, HLS Cores, or IP Integrator Block Diagrams

Are you using System Generator DSP cores, HLS cores, or IP integrator block diagrams in your Dynamic Function eXchange design?

Any type of source can be used as long as it follows the fundamental requirements for Dynamic Function eXchange. Any code processed by System Generator, HLS, or Vivado IP integrator (or other tools) is eventually synthesized. The resulting design checkpoint or netlist must be made up entirely of reconfigurable elements (CLB, block RAM, DSP) for it to be legally included in an RP.

Packing I/Os into Reconfigurable Partitions

Do you have I/Os in RMs?

All I/Os must reside in static logic.

See Design Elements Inside Reconfigurable Modules for more information.

Packing Logic into Reconfigurable Partitions

Is all logic that must be packed together in the same RP?

Any logic that must be packed together must be in the same RP and RM.

See Packing Logic for more information.

Packing Critical Paths into Reconfigurable Partitions

Are critical paths contained within the same partition?

RP boundaries limit some optimization and packing, so critical paths should be contained within the same partition.

See Packing Logic for more information.


Can your RPs be floorplanned efficiently?

See Creating Pblocks for 7 Series Devices for more information.

Recommended Decoupling Logic

Have you created decoupling logic on the outputs of your RMs?

During reconfiguration the outputs of RPs are in an indeterminate state, so decoupling logic must be used to prevent static data corruption.

See Decoupling Functionality for more information.

Recommended Reset after Reconfiguration

Are you resetting the logic in an RM after reconfiguration?

After reconfiguration, new logic might not start at its initial value. If the Reset After Reconfiguration property is not used, a local reset must be used to ensure it comes up as expected when decoupling is released. Clock and other inputs to the RP can also be disabled during reconfiguration to prevent initialization issues. Alternatively, the Reset After Reconfiguration property can be applied. This option holds internal signals steady during reconfiguration, then issues a masked global reset to the reconfigured logic.

See Apply Reset After Reconfiguration for more information.

Debugging with Logic Analyzer Blocks

Are you using the Vivado Logic Analyzer with your Dynamic Function eXchange design?

Vivado Logic Analyzer (ILA/VIO debug cores) can be used in your Dynamic Function eXchange design, but care must be taken when connecting these cores to debug hubs. Use the automatic inference solution shown in Using Vivado Debug Cores.

Efficient Reconfigurable Partition Pblocks

Have you created efficient RP Pblock(s) for your design?

The height of the RP Pblock must align with the top and bottom of a clock region boundary, if the RESET_AFTER_RECONFIG property is to be used. Otherwise, any height can be selected for the RP Pblock.

See Creating Pblocks for 7 Series Devices for more information.

Validating Configurations

How do you validate consistency between configurations?

The pr_verify command is used to make sure all configurations have matching imported resources.

See Verifying Configurations for more information.

Configuration Requirements

Are you aware of the particular configuration requirements for Dynamic Function eXchange for your design and device?

Each device family has specific configuration requirements and considerations.

See Configuring the Device for more information.

Effective Pblock Recommendations

Does an RP Pblock extend over the center clock column or the configuration column in the device?

Due to the back-to-back INT tile requirement for 7 series devices, coupled with the CONTAIN_ROUTING requirement, extending a Pblock over these specialized blocks in the device can make routing very difficult or impossible. Avoid extending an RP Pblock across these areas whenever possible.

See Automatic Adjustments for Reconfigurable Partition Pblocks and Creating Reconfigurable Partition Pblocks Manually for more information on back-to-back requirements.