How do renamed or optimised-away objects break constraints?

Short Answer

The hierarchy and instance names you see after synthesis can drift meaningfully from the original design intent — modules get flattened, renamed, or merged during optimization. When a constraint selector (like a wildcard get_cells pattern) was written against the intent-source names, it can silently resolve to the wrong objects — or to nothing at all — after that renaming happens.

Technical Explanation

• This is exactly the same readiness discipline as reviewing an SDC apply log: the check should leave you with named, resolved objects, and a result that's reproducible by another engineer working from the same handoff.
• The fix isn't cleverer wildcards — it's verifying selector results against actual post-synthesis names every time constraints are reapplied to a new netlist revision, rather than trusting that old patterns still match.

What To Check

• Warning sign: A path exception or generated clock targets an object removed by optimisation.
• Inspect: Compare one named object across the related reports; the same object should tell a consistent story.
• Correct: Use synthesis mapping/handoff evidence to update the constraint at its source and verify exact collection membership.

Healthy, Suspicious & Hard-stop Results

• Expected: Post-synthesis hierarchy and object names may differ from the intent source, causing selectors to resolve incorrectly or not at all.
• 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. ”