Which constraints belong to modes, corners, scenarios, or the netlist?

Short Answer

This is really about knowing the MCMM (multi-mode multi-corner) vocabulary well enough to file each constraint in the right bucket — get the bucket wrong and you either apply a constraint where it shouldn't count, or fail to apply it where it should. ).

Technical Explanation

• ).
• Corners capture operating-condition/parasitic intent — process/voltage/temperature (PVT) conditions and the extraction/derating settings tied to them. A corner doesn't care what the chip is doing functionally; it cares about the physical/electrical conditions the analysis assumes.
• A scenario is simply the active combination of one mode plus one corner — this is the actual unit STA/PD tools analyze against [ICC2: create_scenario -mode M1 -corner C1], and it's what gets activated/deactivated for a given run.
• , via ECO).
• " — that question alone resolves most classification confusion.
• ) and constraints aren't actually active in that scenario — always confirm active status, not just presence.

What To Check

• Warning sign: A constraint is loaded into a context where required scenarios never see it.
• Inspect: Compare one named object across the related reports; the same object should tell a consistent story.
• Correct: Inspect the current scenario and reported scenario associations, then reload the constraint into the owning context.

Healthy, Suspicious & Hard-stop Results

• Expected: Functional intent commonly belongs to modes, operating-condition/parasitic intent to corners, combined analysis status to scenarios, and design-rule constraints can be netlist-specific.
• 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. ”