How do you audit output-delay constraints?

Short Answer

set_output_delay describes what happens outside your block's boundary — specifically, the receiving device's early and late timing requirements relative to its own reference clock. Min and max values aren't interchangeable defaults — they represent the receiver's best-case and worst-case requirement, and both need to be explicitly verified, not just one "typical" number.

Technical Explanation

• Check that the reference clock is actually the correct one the receiver uses, that the edge (rising/falling) and sign convention match the interface spec, and that the values themselves match what the external device datasheet or interface agreement actually states.
• A constraint that's syntactically valid but numerically wrong — say, using the wrong reference clock or an inverted sign convention — will pass every internal sanity check while still describing a physically incorrect interface requirement.

What To Check

• Warning sign: Outputs have only setup-like max requirements or use the wrong virtual clock.
• Inspect: Compare one named object across the related reports; the same object should tell a consistent story.
• Correct: Correct the boundary budget at the source and inspect representative output timing paths.

Healthy, Suspicious & Hard-stop Results

• Expected: Verify receiving reference clock, edges, sign convention, min/max values, and whether the external requirement matches the interface specification.
• 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. ”