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.