The Dynamic Function eXchange design flow uses multiple versions of the design that must be implemented through place and route. These different configurations have common static design results, but differing modules within each RP. Designers must set up timing constraints and floorplans that account for these different modules that will be swapped on the fly.
The DFX Configuration Analysis report compares each RM that you select to give you information on your DFX design. It examines resource usage, floorplanning, clocking, and timing metrics to help you manage the overall PR design.
The DFX Configuration Analysis report is currently run in the Tcl Console or within a Tcl script. The top level design must be open before issuing this command:
report_pr_configuration_analysis -cells <RP_name> -dcps {<list_of_RM_checkpoints>}
Either select a single cell (RP) and multiple DCPs (each representing an RM) that can be inserted into that cell for a comprehensive analysis of that RP, or select multiple cells with no subsequent DCPs for a top-level analysis of the static design and interfaces into each RP.
By default, three aspects of the PR design are analyzed. You can select one or more of these switches to narrow the focus of the report.
- The
-complexity
switch focuses the report on resource usage, including the maximum number of each resource type required for the RP. - The
-clocking
switch focuses the report on clock usage and loads for each RM, helping you plan the overall clocking distribution of the design. - The
-timing
switch focuses the report on boundary interface timing details, allowing you analyze bottlenecks in and out of RMs.
Additionally, the -rent
switch adds Rent metrics
to the report. The Rent exponent calculates the routing complexity and can be an
indication of how much congestion is likely to be seen. For more information on Rent,
see this link in
Vivado
Design Suite User Guide: Design Analysis and Closure
Techniques (UG906). Note that this option can take
a long time to run on large designs.
When this analysis is done, each RM is examined based on information in the
checkpoints provided. While post-synthesis checkpoints can be supplied, if the RM
contains IP that have been synthesized out-of-context, or if debug cores are to be
inserted, information will be missing from these checkpoints. The most complete
information is not available until after opt_design
when all the linking and expansion has been done. Xilinx advises you to create fully
assembled RM checkpoints after opt_design
by calling
write_checkpoint -cell
for each configuration, then
run the configuration analysis report using these files.
Here are some example sections from a report for a design with a single RP that has three RM.