How do you detect the wrong same-named library cell?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
Trusting an instance's reference-cell text string ("this is a NAND2X4") is not the same as verifying it's actually pointing at the NAND2X4 you think it is — the same name can resolve differently depending on reference-library search order. Correlate the actual reference-library resolution order used at the time this instance was placed/optimized — a change in search_path or set_ref_libs order between two runs can cause the same cell name to bind to a different library version.
Technical Explanation
- Check the resolved cell view's identity, not just its name — confirm it's the same PVT-characterized view, from the same library release, that you expect.
- Cross-check the pin interface — if a "same-named" cell from a different library revision has a different pin count, function, or timing arc set, that's strong evidence you're looking at two different cells sharing a name by coincidence.
- Tie this back to handoff version tracking — the manifest/checksum discipline used elsewhere in the flow applies here too: know which library revision was actually loaded for this specific run, not which revision is "supposed to" be in use.
- Don't trust the instance reference text alone as proof of identity — use
report_lib_cell/attribute queries to confirm the actual bound cell definition, library source, and PVT assignment match what the design intends.
What To Check
- Warning sign: Linking succeeds against an unintended library containing the same cell name.
- Inspect: Compare one named object across the related reports; the same object should tell a consistent story.
- Correct: Correct reference setup, relink deliberately, and compare representative resolved cells and timing models.
Command Checks & Actions
- report_ref_libs: shows the reference libraries used for linking
- report_pvt: shows process, voltage, and temperature assignments
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: Correlate reference-library order, cell view identity, PVT assignment, pin interface, and handoff version rather than trusting the instance reference text.
- 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. ”
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
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