ExpertQuestion 5 of 161

A case-analysis constraint removes many paths. How do you decide whether it is valid?

From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

" Trace the constant back to its source object — is it a real strap pin tied at the board level, a fuse/OTP bit, a scan-mode signal, or something else? Each source type has different confidence: a board-level strap is usually solid; a scan/test-mode signal being case-analyzed in the functional SDC is a red flag.

Technical Reference DiagramA case-analysis constraint removes many paths. How do you decide whether it is valid?

Technical Explanation

  • "
  • Trace the constant back to its source object — is it a real strap pin tied at the board level, a fuse/OTP bit, a scan-mode signal, or something else?
  • "
  • g. disables a clock-mux branch) removes not just data paths but potentially whole registers' worth of checks from that scenario; make sure that's intentional and that those registers/clocks are covered in some other active scenario, not silently dropped from all analysis.
  • The overall validity test: correlate the case-analysis value with the specific functional mode it claims to represent, confirm the disabled arcs genuinely can't be exercised in that mode, and confirm you haven't accidentally left some other mode's coverage of those same paths unanalyzed anywhere in your scenario set.

What To Check

  • Warning sign: A test select is fixed in functional mode or a functional select is constrained in every mode.
  • Inspect: Keep at least two possible causes open, then use one named object and the active mode or scenario to separate them.
  • Correct: Correct mode-specific intent, reload the affected context, and compare path and clock coverage before proceeding.

Command Checks & Actions

  • report_case_analysis: shows constants applied for the active mode
  • report_disable_timing: shows timing arcs that cannot propagate
  • report_scenarios: shows the MCMM scenario matrix and analysis status

Run the commands in order. Each line answers a separate part of the check.

Healthy, Suspicious & Hard-stop Results

  • Expected: Correlate the constant with the active functional mode, source object, MUX behaviour, clocks, and disabled arcs.
  • Stop before floorplanning when required logic or timing coverage is missing or unexplained.

Common Mistake

The Trap: Do not assume the check passed just because ICC2 continued. Fix or narrowly justify the named objects, then rerun the same command.

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. ”

Physical Design & Planning Handbook

Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.

Explore Design Planning Guide →

Offline PDF Bundle

Want all 1109 questions offline?

Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.

See what's inside the bundle
Timing Constraints (SDC) Handbook — nine chaptersSDC ConstraintsNine chapters on clocks, exceptions, and constraint linting.

Continue practising

Related PnR (Place & Route) questions

ExpertHow does the tool actually decide what counts as a "root net" for clock NDR purposes, and what's the edge case that can silently change that?ExpertHow does create_clock_straps decide whether it's building a mesh or a spine, and what does -margins actually control?ExpertA generated clock exists by name but has no valid path from its master. How do you diagnose it?ExpertA disabled timing arc removes a clock path. How do you find ownership?