How do you prove no timing check is silently untested?

Short Answer

Run check_timing (PT) first to fix missing clocks, missing I/O constraints and loops, then run report_analysis_coverage (PT) and account for every untested check. With -status_details {untested} the report lists each untested check and the reason, such as no_clock, constant_disabled or no_paths. You have proof when every untested check is either tested in another scenario or has a reason you deliberately created.

Technical Explanation

• Static timing checks every constrained path, but false paths, disabled arcs and case analysis leave some checks untested. An untested check can never violate, so a clean report can hide it.
• The PT UG order is link_design, then check_timing (PT), then report_analysis_coverage (PT), then the rest of the analysis.
• check_timing (PT) runs checks such as no_clock, no_input_delay, unconstrained_endpoints, loops and generated_clocks. -verbose gives detail, and -include, -exclude or timing_check_defaults (PT) change the list. It reports unconstrained endpoints, not startpoints.
• Coverage summarizes setup, hold, recovery, removal, minimum pulse width, clock gating, output setup and hold and more, as met, violated and untested per type.
• -status_details {untested} with -check_type {setup} lists each untested check with its constrained pin, related pin and reason.
• In DMSA the merged report calls a check untested only if every scenario leaves it untested, so scan checks untested in functional mode count as tested when test mode is in focus.
• Rerun coverage whenever constraints or case settings change; one new set_case_analysis (SDC) can untest thousands of checks. Keep the untested list, with its reasons, in the signoff record so a later run can be compared line by line.

What To Check

• Untested percentage per check type.
• Untested checks grouped by reason.
• Whether each reason was intended.
• Which scenarios were in focus for a merged report.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): No untested setup or hold checks in the merged report across functional and test scenarios, or a short list where every reason is documented.
• Suspicious (illustrative): 2% untested with reason constant_disabled on functional logic; a case setting may be tying off logic that should be timed.
• Hard stop: Any untested check with reason no_clock on a register used in mission mode.

What The Interviewer Is Testing

• Knowing a clean slack report proves nothing without coverage.
• The check order and the common untested reasons.
• Do you know the DMSA merged coverage rule?

Follow-up Question & Model Response

"A check is untested in functional mode but tested in test mode. Is that fine?"

Candidate Model Response: Often yes, since scan paths are the classic case and are only meant to be timed in test mode. The merged DMSA report reflects that by calling a check untested only if every scenario leaves it untested. You still confirm the logic is only exercised in test mode. If the same path is live in functional mode, it has to be timed there too, with functional clocks and constraints.