Generating the QoR Suggestion Report - 2022.2 English

Vivado Design Suite User Guide: Design Analysis and Closure Techniques (UG906)
Document ID
UG906
Release Date
2022-10-19
Version
2022.2 English

The report_qor_suggestions command can be accessed in the Vivado® IDE using the Report QoR Suggestions option from the Reports pulldown menu.

Figure 1. Report QoR Suggestions Dialog Box

The equivalent command at the Tcl console is as follows:

report_qor_suggestions -name qor_suggestions_1
To change the timing path limit from the default of 100, change the Number of paths for suggestion analysis shown in the dialog box. This will expand the number of suggestions but they will be on timing paths that might not have been optimized. The equivalent Tcl command-line option is as follows:
-max_paths <N>
To change the number of ML Strategies generated, change the Maximum Number of Strategies to suggest shown in the dialog box. The equivalent Tcl command-line option is as follows:
-max_strategies <N>
To expand the analysis to report suggestions that do not violate threshold criteria, select the Report all suggestions checkbox. The behavior is as follows:
Timing suggestions
Offer suggestions on timing paths regardless of whether timing is met.
Utilization suggestions
Offer suggestions on a resource that is not critical.
Congestion suggestions
Offer suggestions on timing met designs at post-route stage.
The equivalent Tcl command-line option is as follows:
-report_all_suggestions
To generate supporting CSV files showing failing timing paths associated with their suggestions, check the box and specify a directory. The CSV files can make the navigation of timing paths significantly easier to manage than the table in the text report. A second file containing a DONT_TOUCH report is also generated. The equivalent Tcl command-line option is as follows:
-csv_output_dir <directory>
Note: DONT_TOUCH properties prevent the tools from optimizing paths and can be added through the use of other properties automatically by Vivado. Removing DONT_TOUCH properties should be done with care. For instance, the DFX flow uses DONT_TOUCH to prevent cross boundary optimizations between the static and reconfigurable module, so should not be removed. A DONT_TOUCH property added as a result of MARK_DEBUG, by contrast, is not critical to the flow but means that the signal is not available for hardware probing if optimized.