LVS fails with thousands of errors. Where do you start?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
Start with shorts, and among shorts start with power to ground. One VDD-to-VSS short merges both supplies into a single extracted net, so every cell in the block stops matching and one defect shows up as thousands of errors. Clear supply shorts, then signal shorts, then opens, then device and label problems, rerunning after each class, because the count usually collapses long before you reach the bottom of the list.
Technical Explanation
- Read the header of
cell.RESULTS(ICV) first:LVS Compare Results: PASS | FAIL(ICV) andDRC and Extraction Results: CLEAN | NOT CLEAN(ICV). If extraction is not clean, fix that before trusting any compare error. - Shorts come first because they corrupt the extracted netlist for everything attached to them. A supply short makes the power pins of every standard cell look wrong, while an open only affects the nets it splits.
icv -create_lvs_short_output ALL(ICV) runs LVS Short Finder and writes acellname.vue(ICV) file under./run_details/short_out_db(ICV). WithoutALLthe default limit is 200 shorts, reported power-to-ground first, then power-to-power or ground-to-ground, then supply-to-signal, then signal-to-signal, lowest hierarchy level first. Work in that order.- Check for text shorts before hunting geometry. The
text_net()(ICV) function reports text shorts, opens and unused text, so a VDD label dropped on a VSS strap shows up as a short whose fix is the label, not the metal. - Once shorts are gone, open
cell.LVS_ERRORS(ICV). It lists failed equivalence points sorted into high and low priority with diagnostics. A failing low-level cell can drag its parents down with it, so fix the smallest failing cell first and rerun. - Opens come next, since a missing via leaves cells unpowered and they appear as extra nets. Device and property mismatches rarely explain a large count, so they come last.
- Explorer LVS (
icv -explorer_lvs(ICV)) runs a text-based short check on the SOC top cells and skips device extraction, so it turns around fast on a full chip. It needs Elite licensing and does not replace final signoff LVS. - Inside ICC2,
check_lvs(ICC2) finds routing-level shorts, opens and floating routes. It is not transistor-level LVS, but it tells you whether the short exists in the ICC2 database or only appears after the GDS merge.
What To Check
- Both header lines of
cell.RESULTS(ICV): compare result and extraction result. - Short counts by class in the Short Finder output, power-to-ground first.
- Text shorts versus geometric shorts on each supply net.
- High-priority failed equivalence points in
cell.LVS_ERRORS(ICV) and the lowest failing level. - Whether
check_lvs(ICC2) shows the same short in the ICC2 database.
Command Checks & Actions
check_lvs -checks {short open}Routing-level short and open check in the ICC2 database, run before stream-out to see whether the short is already there.
icv -i top.gds -c top -s top.sp -sf SPICE -create_lvs_short_output ALL lvs.rsSignoff LVS run that also writes Short Finder output for every short, not just the default 200.
icv -i top.gds -c top -explorer_lvs lvs.rsFast text-based short check on the SOC top cells with no device extraction; triage only, Elite licensing.
cell.RESULTSCompare and extraction header lines; the first file to read.
cell.LVS_ERRORSFailed equivalence points by priority, read after the shorts are cleared.
Healthy, Suspicious & Hard-stop Results
- Healthy (illustrative): After two supply shorts are fixed the error count falls from 6,214 to 14, extraction reports CLEAN, and a few failed equivalences remain.
- Suspicious (illustrative): The count drops but several hundred errors stay spread across unrelated cells, which usually means a second supply short or a missing power connection.
- Hard stop: Any power-to-ground short still reported, or
LVS Compare Results: FAIL(ICV) on the tapeout GDS.
Common Mistake
The Trap: Opening cell.LVS_ERRORS (ICV) and working down the first few hundred net mismatches one at a time. With a VDD-to-VSS short in the block every one of them is a symptom, and a day of debugging ends only when someone runs Short Finder and finds one via stack dropped across both straps.
What The Interviewer Is Testing
- Does the candidate rank error classes by how many other errors each one can cause?
- Familiarity with the IC Validator outputs: the
cell.RESULTS(ICV) header, Short Finder output andcell.LVS_ERRORS(ICV). - A strong answer keeps the ICC2 routing check apart from transistor-level signoff LVS.
Follow-up Question & Model Response
"How do you locate a power-to-ground short on a large block?"
Candidate Model Response: Rerun LVS with -create_lvs_short_output (ICV) and step through the VUE output from the lowest hierarchy level up. Then check the same area with check_lvs (ICC2). If ICC2 sees it, fix it there and stream out again. If ICC2 is clean, the short came in with merged GDS, often a macro, a fill cell or a pad ring, so compare the merged layer data at that spot.
Practical Example
Tapeout Scenario: A block returns 6,214 LVS errors (illustrative). Short Finder reports two power-to-ground shorts, both at the edge of an SRAM where an M5 VSS strap overlaps internal VDD metal inside the macro GDS. check_lvs (ICC2) is clean because the macro frame view carries pins and blockages, not that internal metal as net shapes. Trimming the strap and rerunning drops the count to 14, all in one analog cell with a swapped label. After the label fix, cell.RESULTS (ICV) reads PASS and CLEAN.
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.
Continue practising