What does check_timing report, and why must you run it before trusting any slack number?

Short Answer

check_timing (PT) scans the design for constraint problems that would make timing analysis incomplete or simply wrong — flops with no clock defined, ports with no input or output delay, generated clocks whose source pin cannot be found, and combinational feedback loops. Under-constraint is silent: a design missing constraints can still produce a fully green, all-passing report_timing (PT) that means nothing.

Technical Explanation

• What check_timing actually looks for. Rather than computing slack on any path, check_timing (PT) audits the constraint setup itself — flagging registers with no clock reaching their clock pin, input or output ports with no delay constraint at all, generated clocks whose declared -source pin does not actually exist or trace back correctly, and combinational loops that have no clear startpoint or endpoint.
• Why a clean report_timing can still hide a real problem. report_timing (PT) can only ever report on paths the tool believes need checking. If a flop has no clock defined, or a port has no input delay, the tool typically has nothing to compute a required time from for those paths — they are simply absent from every timing report, not flagged as failing.
• Why absence looks identical to success. A design summary showing zero setup violations and zero hold violations looks exactly the same whether every path was genuinely checked and passed, or whether some paths were silently never checked at all because of a missing constraint.
• Why this has to run first, not last. Trusting any slack number — WNS, TNS, or a single path's result — assumes the constraint set that produced it is complete. Running check_timing before relying on any slack number verifies that assumption instead of taking it on faith.
• What a typical output looks like. check_timing groups its findings by category — for example "unclocked register," "no input delay," "loops" — so each class of constraint gap can be triaged and fixed as its own item, rather than as one undifferentiated list of design problems.

Follow-up Question & Model Response

If check_timing reports an unclocked register, does that always mean the RTL forgot to connect a clock to that flop?

Candidate Model Response: Not always — it can also mean the clock is connected in the netlist but the SDC never defined a clock object on that pin, for instance if a clock domain was added late and its create_clock command was never written, or if the clock reaches the flop through a path the tool does not recognize as a valid clock network, such as through a data-path gate rather than a proper clock buffer. Either way, the practical response is the same: trace the physical connection first to rule out an RTL bug, then check the SDC file for a missing or misplaced clock definition, since check_timing itself cannot tell you which of the two it is, only that the clock pin has no timing clock reaching it.