A disabled timing arc removes a clock path. How do you find ownership?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
A "disabled arc" just means STA has been told to stop propagating timing through a specific point in a cell or net — and when that happens on a clock path, an entire downstream clock tree can silently go unanalyzed, which is a lot scarier than a disabled arc on a random data path. The first job isn't to re-enable it blindly — it's ownership hunting: figure out who disabled it and why, because the fix is completely different depending on the source.
Technical Explanation
- It could come from the library model itself (some cells have built-in disabled arcs for non-functional paths, like a scan-mux select arc that's legitimately never active in a given mode).
- It could come from a user constraint — someone explicitly ran
set_disable_timingfor a reason that may or may not still be valid. - It could come from case analysis — a
set_case_analysisconstant on a control pin that structurally disables a path only in the mode currently being analyzed (which is correct behavior, not a bug, if that mode really does tie that pin off). - It could come from combinational loop breaking — the tool automatically disables an arc to cut a timing loop, and if that loop happens to be on a clock path, you get a legitimately broken clock analysis that needs a real SDC exception instead of a silent auto-cut.
- The debug method is the same regardless of source: trace the specific pin/arc back through
report_disable_timing-style queries, cross-reference active case-analysis settings and SDC exceptions for that scenario, and don't declare it "fixed" until you know exactly which mechanism owns the disable and whether that's actually correct for this mode.
What To Check
- Warning sign: A clock object exists but cannot traverse gating or MUX logic.
- Inspect: Keep at least two possible causes open, then use one named object and the active mode or scenario to separate them.
- Correct: Correlate disable and case reports with library/netlist intent, then correct the owning source rather than forcing propagation.
Command Checks & Actions
report_disable_timing: shows timing arcs that cannot propagatereport_case_analysis: shows constants applied for the active mode- report_clocks: shows clock definitions and relationships
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: Determine whether the disable comes from a library model, user constraint, case analysis, loop breaking, or mode-specific condition.
- 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
Master ASIC Physical Design Planning & Floorplanning
Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.
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.
Continue practising