How do you approve an intentional undriven or unloaded object?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
Signing off a waiver on an undriven/unloaded net or pin is a real engineering decision, not a rubber stamp — treat it with the same rigor as any other design-affecting approval. Require named-object evidence first: exactly which net, pin, or port is being waived — never approve a waiver at the level of "there are 40 undriven pins in this category," because that hides individual cases that might not actually be safe.
Technical Explanation
- Require a functional reason, not just an observation — why is this legitimately undriven/unloaded? )
- Identify which modes the waiver applies to — an object that's legitimately undriven in one operating mode might be a real bug in another, so the waiver has to state its scope precisely, not blanket-cover every mode.
- Name an owner and document the risk — who is accountable if this turns out to be wrong, and what's the actual downside if the assumption is incorrect (functional failure? just excess leakage? ).
- The waiver must be rerun-stable — it should still correctly apply after a netlist ECO or re-synthesis, which means it needs to be tied to something durable (an object name/pattern with real justification), not just a one-time message count that happens to match today's run. Never waive purely by suppressing a message count — that approach breaks silently the moment the underlying count changes for an unrelated reason.
What To Check
- Warning sign: A test output is intentionally unused, but the waiver pattern also captures functional logic.
- Inspect: Keep at least two possible causes open, then use one named object and the active mode or scenario to separate them.
- Correct: Narrow the waiver record, fix any accidental objects, and prove the remaining set is identical after a clean rerun.
Command Checks & Actions
- check_netlist: reports structural connectivity problems
- report_ports -verbose [get_ports *]: shows boundary constraints and electrical assumptions
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: Require named-object evidence, functional reason, affected modes, owner, risk, and a rerun-stable waiver; never waive only a message count.
- 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