The QoR Assessment Details table, shown in the following figure, gives a convenient design overview that highlights issues in the following areas that form the basis of the RQA score.
- Utilization
- Netlist
- Clocking
- Congestion
- Timing
The table shows design characteristics broken into five categories. Each category is marked OK when there are no sub-items marked REVIEW. When sub-items are marked REVIEW, the failing item is displayed with its threshold and current value. The thresholds are not hard limits and can be exceeded, but going over these limits can make timing closure difficult. Pay particular attention when thresholds are significantly exceeded or when many categories are exceeding their thresholds. Items marked with an * do not directly contribute to the score but may be critical to whether the design will meet timing and should be reviewed.
Utilization checks are performed on the whole device, at the SLR level
and the Pblock level. Running report_qor_suggestions
can help reduce utilization.
Netlist checks are performed on the netlist structure and non timing constraints. These will identify items with DONT_TOUCH properties, high fanout nets with poor driver profiles and other design features that could add difficulty to the implementation tools.
Clocking shows whether there is high clock skew on setup or hold paths. Details
of failing clock skew paths are automatically added to the report in the Vivado IDE. In text mode, add ‑csv_output_dir <directory> to generate the timing paths in CSV
format. Running report_qor_suggestions can give
automated fixes to many clock skew issues.
Congestion looks into the netlist for profiles that can contribute to routing
congestion. Congested region information is not available before placement but some
netlist items are available. You might wish to evaluate congestion by running place and
route before fixing these items. Run report_qor_suggestions to generate suggestions that reduce congestion
targeted at cells in the congested area.
- WNS, TNS, WHS, and THS to determine whether it is likely the design can close timing.
- Net budget checks: for routable nets, a conservative net delay is added instead of the estimated delay.
- LUT budget checks: for LUTs, the delay is swapped for a conservative LUT delay instead of using the estimated delay.
LUT and net budget checks allow an estimate that is less than ideal. Resolve paths that exceed the slack to reduce the number of issues seen later in the design flow. Examine the Challenging Timing Paths section in the Vivado IDE or generate a CSV file to see more information on these paths.
On a routed design, additional features are checked to see if the design can close using the last mile directive that is leveraged internally within the Intelligent Design Runs feature. This will check, whether timing paths can meet timing based on WNS, WHS, pre and post path slack and the primitives involved in the worst case timing paths.