Configuration Analysis Report - 2023.1 English

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). 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. AMD 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.