What does the check_timing command do, and why should you run it before trusting any report?
From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
The check_timing (PT) command audits the loaded design and constraints for setup problems that would make slack reports meaningless — unclocked registers, unconstrained ports, and combinational loops — before you rely on any slack number it produces.
Technical Explanation
A clean-looking slack report proves nothing if part of the design was never actually checked in the first place, and check_timing (PT) is what catches that gap before it becomes a silent one.
- Unclocked registers: flags any register whose clock pin never actually receives a clock, which means its data path was never timed at all.
- Unconstrained ports: flags input or output ports missing
set_input_delay(SDC) orset_output_delay(SDC), so their boundary paths were skipped rather than checked and passed. - Combinational loops: flags circular logic the tool had to break arbitrarily at some point just to compute a delay, which means that loop's true timing was never actually verified.
- Clock relationship problems: flags clocks the tool could not resolve a fixed period relationship between, leaving some path pairs unanalyzed by default.
- Why this matters more than any single slack number: a design can show zero violations purely because thousands of paths were silently excluded from analysis, not because those paths actually meet timing.
Common Mistake
The Trap: Treating a slack report with zero violations as proof the design meets timing, without ever running check_timing first.
- A typo in a clock definition can leave thousands of registers with no clock reaching their clock pin at all.
- Every one of those registers is simply absent from the slack report — not passing, just never checked.
Follow-up Question & Model Response
How is check_timing different from check_design, since both sound like sanity checks?
Candidate Model Response: check_design is run earlier in the flow, in synthesis or place-and-route, not in PrimeTime — it verifies netlist connectivity issues, such as unconnected pins, a net driven by more than one source, or floating inputs, problems with the circuit's structure rather than its timing. check_timing (PT) verifies the timing setup specifically: clocks, constraints, and whether every path actually has coverage. I would run both before trusting any report, since a structurally broken netlist can produce misleading timing results even if the constraints themselves look correct.
Practical Example
Running check_timing -verbose on a block ahead of signoff flags 340 registers under no_clock, traced back to a typo in a generated-clock name that left an entire sub-block's clock tree undriven. Fixing the typo and re-running the check clears the warning and, only then, surfaces roughly 60 real setup violations that had been silently invisible the whole time.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising