What does check_timing report, and why must you run it before trusting any slack number?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Explanation
check_timing scans the design for constraint problems that would make timing analysis incomplete or wrong — things like flops with no clock, ports with no output or input delay, generated clocks whose source can't be found, and combinational loops. Under- constraint is silent: a design missing constraints can still produce a green (all-passing) report_timing that means nothing.
Timing-path Walkthrough
In the worked example output, check_timing flags 3 unclocked_registers (flops whose CK pin has no clock — untimed and needing a fix), 12 unconstrained_endpoints (ports with no output delay, leaving the boundary unchecked), 5 no_input_delay ports (inputs with no arrival reference), 1 generated_clocks warning (a generated clock's source not found), and 1 combinational loop needing to be broken.
Command
check_timingExpected Report Behavior
check_timing output lists each category of problem (unclocked_registers, unconstrained_endpoints, no_input_delay, generated_clocks, loops) with counts, distinct from and run prior to report_timing's slack numbers.
Mentor Note — Common Mistake
Trusting a fully passing report_timing without first running check_timing, not realizing the design may be silently under-constrained (e.g., unclocked flops or unconstrained ports never even being checked).
How To Debug
Run check_timing before relying on any slack number, and resolve every flagged category (unclocked registers, unconstrained endpoints, missing input delays, unresolved generated clock sources, loops) since a clean-looking report_timing on an under-constrained design is meaningless.
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising