Building Up Implementation Requirements - 2024.2 English - 2024.1 English

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

Document ID
UG909
Release Date
2024-11-13
Version
2024.2 English

Implementation of Dynamic Function eXchange designs requires that certain fundamental rules are followed. These rules have been established to ensure that a partial bitstream can be accurately created and safely delivered to an active device. As noted throughout this document, these rules include these basic premises:

  • The logical and physical interface of a RP remains consistent as each RM is implemented.
  • The logic and routing of a RM is fully contained within a physical region which is then translated into a partial bitstream.
  • The logic of the static design must be kept out of the reconfigurable region if the dedicated initialization feature is used.

These requirements necessitate specific implementation rules for optimization, placement and routing. Application of these rules might make it more difficult to meet design goals, including timing closure. A recommended strategy is to build up this set of requirements one at a time, allowing you to analyze the results at each step. Starting with the most challenging configuration and the full set of timing constraints, implement the design through place and route and examine the results, making sure you have sufficient timing slack and resources available to continue to the next step.

  1. Implement the design with no Pblocks. Use bottom-up synthesis and follow general Hierarchical Design recommendations, such as registered boundaries, to achieve a baseline result.
  2. Add Pblocks for the design partitions that will later be marked reconfigurable. This floorplan can be based on the results established in the bottom-up synthesis run from Step 1. Logic from the RMs must be placed in the Pblocks, but static logic may be included there as well.

    While creating these Pblocks, the HD.RECONFIGURABLE property (and optionally, the RESET_AFTER_RECONFIG property) can be added temporarily to run PR-specific Design Rule Checks. This ensures that the floorplan created meets PR size and alignment requirements.

  3. With the floorplan established, separate the placement of static design resources from those to be reconfigurable by adding the EXCLUDE_PLACEMENT property to the Pblocks. This keeps static logic placed outside the defined Pblocks.
  4. Keep the routing for RMs bound within the Pblocks by applying the CONTAIN_ROUTING property to the Pblocks. With the properties from this and the previous step, the only remaining rules relate to boundary optimization procedures as well as PR-specific Design Rule Checks.
  5. Finally, mark the RP Pblocks as HD.RECONFIGURABLE. The EXCLUDE_PLACEMENT and CONTAIN_ROUTING properties are now redundant and can be removed.

If design requirements are not met at any of these steps, you have to opportunity to review the design structure and constraints in light of the newly applied implementation condition.