How do you compare functional and test-mode readiness?

Short Answer

Functional mode and test mode are not interchangeable checks of the "same thing twice" — they're genuinely different operating conditions with different clocks, different constants, and different expected behavior, and a clean result in one mode tells you nothing conclusive about the other. Compare clock definitions separately per mode — test mode very often uses different clock sources, different frequencies, or scan-clock muxing that functional mode never exercises, and vice versa.

Technical Explanation

• Compare tied constants separately — signals that are constant in test mode (like scan-enable) are often dynamic in functional mode, and case-analysis settings that are correct for one mode are actively wrong if reused unchanged in the other.
• Compare I/O constraints separately — input/output delays and port behavior can differ meaningfully between the two modes, especially around scan I/O and boundary-scan pins that don't exist as "real" functional interfaces.
• Compare timing exceptions separately — a false path or multicycle path that's valid in functional mode might not apply (or might apply differently) in test mode, and blindly reusing exceptions across modes is a common source of missed coverage.
• Compare which checks are actually active in each mode — DRC/timing checks that get suppressed or altered under scan conditions need explicit verification, not an assumption they behave the same as functional mode.
• Compare the expected sequential element population — scan reconfiguration can change which flops are actually exercised or observable in a given mode, and readiness review needs to confirm that population matches what's expected for that mode.
• The bottom line: neither mode can substitute for the other in a readiness review — you need separate, explicit evidence for each, covering all of the above.

What To Check

• Warning sign: Functional mode is complete while scan/test clocks leave large no_clock groups.
• Inspect: Keep at least two possible causes open, then use one named object and the active mode or scenario to separate them.
• Correct: Return missing test intent to DFT/STA ownership or document why that mode is outside the current floorplanning gate.

Healthy, Suspicious & Hard-stop Results

• Expected: Compare clocks, constants, I/O constraints, exceptions, active checks, and expected sequential populations separately; neither mode substitutes for the other.
• 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.

Follow-up Question & Model Response

Model response: “I would save the report, inspect one affected object in the correct block and scenario, and make or request this correction. ”