What does check_timing check at this stage?

Short Answer

check_timing is not a timing-quality check (it doesn't report slack) — it's a setup/coverage health check that runs before you should trust any slack numbers at all. It looks specifically for missing or inconsistent timing intent: clock pins with no clock reaching them ("no-clock" points), output/register endpoints that never got constrained (unconstrained endpoints), timing loops (combinational cycles that break static analysis), and generated-clock definition problems (a derived clock missing its source or divide-by relationship).

Technical Explanation

• " — those are two completely different questions, and skipping this one means any slack report you look at afterward could be silently wrong or incomplete.
• A common trap: a design can report zero violations in a timing summary simply because huge chunks of it were never actually constrained — check_timing is what catches that, a slack report by itself won't.
• Practically, review every category check_timing flags (there are several selectable categories beyond the four above) before you start trusting or optimizing against any timing numbers — celebrating "clean timing" without running this first is a classic beginner mistake.

What To Check

• Warning sign: Ordinary timing reports look clean because problematic paths never entered analysis.
• Inspect: Start with one named object in the report and trace it to the netlist, library, or SDC statement that created it.
• Correct: Run defaults first, add relevant named checks deliberately, classify every finding, and rerun after correction.

Healthy, Suspicious & Hard-stop Results

• Expected: It diagnoses missing or inconsistent timing setup such as no-clock points, unconstrained endpoints, loops, generated-clock issues, and other selected categories.
• Stop before floorplanning when required logic or timing coverage is missing or unexplained.

What The Interviewer Is Testing

Be ready to explain why this matters before floorplanning.