When timing closure is difficult to achieve or when you are trying to improve the overall performance of your application, you must review the main characteristics of your design after running synthesis and after any step of the implementation flow. It is relatively easy to gather the high-level metrics such as timing summary numbers (WNS/TNS/WHS/THS) (
report_timing_summary) or various resource utilization numbers (
report_control_sets). But it is more difficult to analyze and identify which particular aspect of your design is impacting a specific timing path and consequently the overall Quality of Result (QoR). The QoR analysis usually requires you to look at several global and local characteristics at the same time to figure out what is suboptimal in the design and the constraints, or which logic structure is not suitable for the target device architecture and implementation tools. The
report_design_analysis command gathers logical, timing and physical characteristics in a few tables that can simplify the QoR root cause analysis.
report_design_analysiscommand does not report on the completeness and correctness of timing constraints. To verify your timing constraints, you must use the
report_exceptionscommands, as well as the XDC and TIMING methodology DRCs. For more information on how to run these commands, see the corresponding sections:
Two main categories of QoR problems are usually encountered: