Why can a very low unconstrained-endpoint count coexist with poor coverage?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
A low unconstrained-endpoint count sounds like good news, but "unconstrained" and "well-covered" are answering different questions — an endpoint can have some constraint applied and still be poorly covered by real timing analysis. False paths silently remove endpoints from meaningful analysis without making them "unconstrained" — the constraint exists [SDC: set_false_path], so the endpoint doesn't show up as missing anything, but it's also not being genuinely checked.
Technical Explanation
- Case analysis has the same effect — a
set_case_analysisvalue that removes a whole branch of logic from active consideration makes paths through it disappear from analysis while leaving no trace in the unconstrained-endpoint count. - Disabled timing arcs [SDC:
set_disable_timing] similarly remove real paths from the timing graph without those endpoints ever looking "unconstrained" — they were constrained, then deliberately excluded. - Inactive scenarios are a scope problem, not a per-endpoint problem — if the scenario that actually exercises a given mode isn't active, none of its endpoints will show up as unconstrained even though nothing meaningful is being checked in that mode right now.
- Missing clocks on a downstream path can also produce this illusion in specific ways depending on how the missing clock interacts with existing exceptions — the common thread across all these causes is: don't trust a single summary count, trace actual named paths through named endpoints to confirm real coverage exists, not just the absence of an "unconstrained" flag.
What To Check
- Warning sign: The dashboard reports few unconstrained endpoints while whole interfaces or modes are absent.
- Inspect: Keep at least two possible causes open, then use one named object and the active mode or scenario to separate them.
- Correct: Audit scenario status, clocks, exceptions, case analysis, disabled arcs, and expected path groups; stop until coverage is explained.
Command Checks & Actions
- report_scenarios: shows the MCMM scenario matrix and analysis status
- report_clocks: shows clock definitions and relationships
- report_exceptions: shows timing exceptions and their scope
report_case_analysis: shows constants applied for the active modereport_disable_timing: shows timing arcs that cannot propagate
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: False paths, case analysis, disabled arcs, inactive scenarios, or missing clocks can remove paths before they become unconstrained endpoints.
- 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