Each step of the implementation flow performs design rule checks (DRCs) unique to partial reconfiguration. Keep a close eye on the messages given by the implementation steps to ensure no critical warnings are issued. These messages provide guidance to optimize module interfaces, floorplans, and other key aspects of DFX designs.
Most reports that can be generated do not have DFX-specific sections, but useful
information can be extracted nonetheless. For example, utilization information can be
obtained by using the
-pblocks switch for the
report_utilization command. This shows the used and
available resources within a given RM. Here is an example using the design from the
Design Suite Tutorial: Dynamic Function eXchange (UG947):
report_utilization -pblocks [get_pblocks pblock_count]
For clock reporting, however,
report_clock_utilization shows the clocks reserved for partial reconfiguration implementation.
The Dynamic Function eXchange flow can be used in conjunction with the IEEE-1735 v2 encryption capability available withinVivado. Static design checkpoints can be encrypted and shared with other users without exposing details of the design. Rights management can be set such that details such as LUT contents and schematic details can be hidden, and netlist export and design modification can be disabled. Developers of dynamic regions can still insert their reconfigurable logic and implement within this locked static context. If permission is given, these developers can generate partial bitstreams from within this encrypted context for their dynamic function.
Note that a license is required to use this feature, and any licensed IP within the static region will still require a valid license to open that checkpoint even if it is encrypted.
For more information on creating encrypted design checkpoints and the options available, please consult Chapter 6 of Vivado Design Suite User Guide: Creating and Packaging Custom IP (UG1118).