Quality of Results (QoR)
Reading QoR across timing (WNS/TNS/WHS + the slack histogram), area, power and design-rule legality, how to read report_qor, and fixing QoR in priority order.
Quality of Results is how you measure whether a synthesis (or physical design) run was any good. It is never a single number: QoR spans timing, area, power and design-rule compliance at once, and improving one usually costs another. A senior engineer reads all of them together and knows which to trade. report_qor is the command that prints the scoreboard.
The four dimensions
Every run is judged on four axes. Timing, is it fast enough. Area, is it small enough. Power, is it efficient enough. Design rules, is it electrically legal. A netlist that closes timing but blows the area budget, or meets area but leaks too much, has bad QoR even though one number looks great. The skill is balancing them for your target, not maximising any one.
Timing metrics
Timing QoR is read from a handful of numbers. WNS (Worst Negative Slack) is the single most critical path, the one that sets your maximum frequency; it must be ≥ 0 to sign off. TNS (Total Negative Slack) is the sum of the negative slack over every failing endpoint, it tells you how much total work remains, so a small WNS with a huge TNS means many paths are failing by a little. Failing endpoints counts how many paths miss. And WHS (Worst Hold Slack) is the worst short-path (hold) violation, hold failures happen at every frequency and are fixed with delay buffers, never by slowing the clock.
The slack histogram above is how engineers see timing QoR at a glance: endpoints binned by slack, negative bins red. A design that is close will have a tall wall of endpoints just to the right of zero; a design in trouble has a long red tail on the left.
Area and power metrics
Area is reported as total cell area (and often split into combinational vs sequential) and as a cell count; utilisation is that area as a fraction of the available core. Power splits into dynamic (switching, which scales with activity and frequency) and leakage (static, set mostly by threshold-voltage mix). Feeding realistic switching activity (a SAIF file) makes the power number trustworthy rather than a worst-case guess.
Design rules and congestion
Two more numbers gate a run. DRC here means the electrical design-rule violations, max transition, max capacitance and max fanout, which the netlist must satisfy regardless of timing; a design with DRC violations is not legal even if timing is clean. And congestion (from an early global route estimate) warns whether the placement will actually route. Both belong in the QoR picture because a fast netlist that cannot be routed is worthless.
Reading report_qor
report_qor prints all of this in one place. You scan timing first (WNS/TNS/endpoints), confirm hold is not wildly off, then check area and power against budget and look for DRC or congestion flags.
report_qor
Timing (setup / max)
WNS ................ -0.084 ns
TNS ................ -3.20 ns
Violating endpoints 42
Timing (hold / min)
WHS ................ 0.011 ns
Area
Combinational ..... 18342 um^2
Sequential ........ 9120 um^2
Total cells ....... 26310
Power
Dynamic ........... 142.6 mW
Leakage ........... 8.9 mWImproving QoR
When the scoreboard is red, fix in priority order: legality and hold first (they are structural), then setup, then recover area and power on the paths that have slack.
| Issue | Symptom | Fix | Priority |
|---|---|---|---|
| DRC (electrical) | max_transition / cap / fanout violations | Buffer, upsize drivers, split fanout | Highest (legality) |
| Hold violation | Negative WHS | Insert delay / hold buffers | High (all frequencies) |
| Setup violation | Negative WNS / TNS | Restructure, upsize, retime, fix SDC | High |
| Area over budget | High cell count / utilisation | Downsize slack paths, resource sharing | Medium |
| Power over budget | High dynamic / leakage | Clock gating, multi-Vt, activity-aware opt | Medium |
| Congestion | Global-route overflow warnings | Spread cells, blockages, fix floorplan | Medium |
Watch the synthesis-to-layout correlation. Synthesis QoR is optimistic because it estimates wire delay before placement; a run that is barely closing at synthesis will usually fail after routing. Leave margin, and use physically-aware synthesis (DC topographical / Fusion, Genus iSpatial) so the QoR you see is closer to the QoR you get.
Recap: QoR is timing, area, power and design-rule legality read together. Track WNS/TNS/endpoints and WHS for timing, area and utilisation, dynamic and leakage power, and DRC/congestion for legality and routability. Fix legality and hold first, then setup, then recover area and power, and never trust synthesis QoR without leaving margin for the layout.