What evidence proves timing is closed?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
Timing is closed only when PrimeTime shows no violations in every signoff scenario and you can prove the analysis covered everything it should. That means clean constraints, no unexplained untested checks, no setup, hold or DRC violators, SI enabled, and any path saved by PBA confirmed with exhaustive analysis. A clean WNS number alone is not evidence.
Technical Explanation
- All signoff scenarios must be run, every mode at every required corner, because a scenario that was not timed cannot show a violation.
check_timing(PT) must be clean or every warning explained: unclocked registers, missing input delays, unconstrained endpoints and loops all hide paths from the analysis.report_analysis_coverage(PT) summarizes tested and untested checks across the scenarios.-status_details {untested}lists each untested check with its reason, such as no startpoint clock or a constant from case analysis.report_constraint -all_violators(PT) must show no setup, hold, max transition, max capacitance or other violators. ICC2's equivalent isreport_constraints(ICC2), with a plural name.- Crosstalk analysis must be on, with
si_enable_analysis(PT) and coupling parasitics loaded, so delta delays and noise are included. - Any path that passes only after PBA must pass with
report_timing -pba_mode exhaustive(PT), not path mode or machine learning mode. - Keep the reports, the constraints and parasitics versions and the tool versions together, so anyone can reproduce the claim.
What To Check
- Scenario list against the signoff specification.
check_timing(PT) warnings, each fixed or explained.- Untested checks and their reasons.
- Violators of every type in
report_constraint(PT). - PBA exhaustive results for any path that was violating in GBA.
Command Checks & Actions
check_timingFinds constraint holes such as unclocked registers and unconstrained endpoints.
report_analysis_coverage -status_details {untested}Lists untested timing checks with the reason for each.
report_constraint -all_violatorsLists every setup, hold and DRC violator.
report_timing -pba_mode exhaustive -slack_lesser_than 0Confirms no path still violates after exhaustive recalculation.
Healthy, Suspicious & Hard-stop Results
- Healthy (illustrative): Every scenario clean in
report_constraint -all_violators(PT), no unexplained untested checks, and no PBA exhaustive violators. - Suspicious (illustrative): Several hundred untested checks, all with the reason constant_disabled from a documented test mode case setting; acceptable once each group is reviewed.
- Hard stop: A register bank reported with no_startpoint_clock or no clock at all, or a scenario never run. The block is not closed.
Common Mistake
The Trap: Showing a clean report_constraint (PT) as proof of closure without looking at coverage. A generated clock was missing from the constraints, so 3,000 registers were never timed, and a clean report meant nothing for them. report_analysis_coverage (PT) would have shown those checks as untested in a single line.
What The Interviewer Is Testing
- Knowing that a clean report can come from missing constraints.
- Can you list what must be clean, and in which scenarios?
- Separating PBA path mode from exhaustive for signoff.
Follow-up Question & Model Response
"Are untested checks always a problem?"
Candidate Model Response: No. Some checks are untested for good reasons, for example outputs held constant by a documented test mode case setting, or false paths agreed with the design team. What matters is that every untested check has a reason someone has reviewed and accepted. An untested check caused by a missing clock or missing input delay is a real hole, because paths behind it are never timed. I would review untested checks by reason and sign off each group explicitly.
Practical Example
Tapeout Scenario: Before handoff, check_timing (PT) reports 0 unclocked registers and 2 unconstrained output ports, both test outputs covered by a documented false path (illustrative). report_analysis_coverage (PT) shows 98.6 % of setup checks tested; the 1.4 % untested are all constant_disabled from the test mode setting. report_constraint -all_violators (PT) is empty in all 8 scenarios, SI is on, and 6 paths that were −2 to −4 ps in GBA pass PBA exhaustive at +1 to +5 ps. That set of reports, stored with the tool, constraint and parasitic version numbers, is the closure evidence, and anyone who reruns it should get the same result.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
Continue practising