How do you read `report_qor`?

Short Answer

report_qor (PT) gives the one-page state of a design, organized by path group. Read it group by group, checking worst slack, TNS and number of violating paths, then the hold and design rule summaries; in PT, report_constraint (PT) lists the individual design rule violators behind those counts. The PT and ICC2 versions have the same idea and different numbers, because the engines, parasitics and settings differ.

Technical Explanation

• report_qor (PT) gives an overview per path group. The PT user guide lists what it contains: critical path length, which is the arrival time at the endpoint, total negative slack, minimum delay and hold, and a detailed design rule constraints summary. report_constraint (PT) then names the individual violating pins and nets.
• report_qor (ICC2) reports per scenario and per path group: levels of logic, critical path length, critical path slack, clock period, TNS and number of violating paths, plus hold sections, cell count, area and design rules. By default it covers all active scenarios.
• Critical path length is not slack. A long path in a slow clock group can be fine, while a shorter path in a faster group fails, so always read the slack next to it.
• TNS in PT uses union mode by default, timing_report_union_tns (PT) set to true: each violating endpoint counts once, even if it is in two groups. In every-group mode it counts once per group, so the two modes can give different totals for the same design.
• The design rule section of report_qor (ICC2), and the design rule summary of report_qor (PT), count transition, capacitance and other DRC violations. Read them before timing, since DRC problems distort delay calculation.
• PT and ICC2 numbers differ because ICC2 uses its own delay calculation, extraction mode and analysis settings chosen for optimization, while PT uses signoff parasitics, SI and its own delay calculation. Compare trends and gaps, not exact values.
• report_timing (PT) and report_timing (ICC2) differ in the same way. When numbers disagree, first check that both runs have the same scenarios, constraints and derates.

What To Check

• Scenario and path group headings, so you know which block you are reading.
• Worst slack, TNS and violating-path count for each group, setup and hold.
• Design rule counts: transition and capacitance violations from the design rule sections of report_qor (ICC2) and report_qor (PT), with report_constraint (PT) for the violator list.
• The TNS mode in PT and the scenarios included in ICC2.
• The PT and ICC2 values for the same group and scenario, and the size of the gap.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): All groups at slack at or above 0 ps with no violating paths, zero DRC nets, and a PT to ICC2 gap of a few picoseconds that stays stable between runs.
• Suspicious (illustrative): ICC2 shows 12 violating paths in a group where PT shows 70, with most of the extra paths on long nets; look at extraction and SI settings.
• Hard stop: Hundreds of max capacitance violations in the design rule section while timing looks clean; the timing numbers cannot be trusted until DRC is fixed.

What The Interviewer Is Testing

• Knowing that critical path length is an arrival time, not a slack.
• Can you explain why PT and ICC2 report different values for the same design?
• Checking the design rule section before trusting any timing number.

Follow-up Question & Model Response

"The ICC2 report says TNS −0.8 ns and PT says −2.1 ns. Where do you look first?"

Candidate Model Response: I would check that both runs use the same scenarios, constraints and derates, because a missing scenario or a derate difference explains big gaps quickly. Next I would compare the worst few endpoints from each tool to see whether the gap is spread evenly or concentrated on certain nets. If it sits on long or crowded nets, extraction and SI differences are the likely cause. I would also check the TNS mode in PT, since union and every-group modes can give different totals.