What are the most common LVS failures?

Short Answer

The usual LVS failures are shorts, opens, missing or extra devices, and port or label mismatches. Shorts and opens come mostly from routing and ECO edits, device mismatches from wrong cell versions or wrong views at stream-out, and port problems from text labels. ICC2 can catch routing-level shorts and opens early; IC Validator gives the signoff answer.

Technical Explanation

• Shorts happen when shapes of two different nets touch or overlap. A short merges two nets into one extracted net, and the comparison then fails on every device connected to both. Power-to-ground shorts are the most damaging and are usually the first thing to hunt.
• Opens happen when a net's pins are not all connected by its shapes: a missing via, a wire that stops short, or a pin that was never reached. The extracted net splits into pieces, and LVS reports the pieces as unmatched nets.
• Missing or extra devices usually come from cell data, not routing. A standard cell or macro GDS that differs from the version assumed in the reference netlist, or a filler or decap written with the wrong view, shows up as devices that exist on only one side.
• Port and label mismatches come from text. A pin label on the wrong shape, a label on the wrong layer, or two labels on one net makes the tool name nets wrongly or report two ports shorted.
• ICC2 check_lvs -checks {short open floating_routes} (ICC2) is a routing-level check on the design library. It reports shorted nets, open nets and floating net shapes. By default it reports up to 20 violations per error type; -max_errors 0 removes the limit. It does not extract transistors.
• IC Validator gives the signoff result. cell.RESULTS (ICV) starts with LVS Compare Results: PASS | FAIL (ICV), and cell.LVS_ERRORS (ICV) lists failed equivalence points in priority order with diagnostics.
• One root cause can create thousands of messages. A single VDD-VSS short can make every cell in a region mismatch, so always look for the short before chasing individual errors.

What To Check

• The first header line of cell.RESULTS (ICV): PASS or FAIL.
• The second header line, DRC and Extraction Results: CLEAN | NOT CLEAN (ICV), which catches extraction and text problems.
• Any supply-to-supply short, before looking at signal nets.
• Failed equivalence points in cell.LVS_ERRORS (ICV), starting with the high-priority list.
• ICC2 check_lvs (ICC2) short and open counts on the same database state that was streamed out.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): check_lvs (ICC2) reports 0 shorts, 0 opens and 0 floating routes, and cell.RESULTS (ICV) shows PASS with extraction CLEAN.
• Suspicious (illustrative): LVS PASS but 3 floating route shapes in check_lvs (ICC2); harmless metal today, but it should be removed before fill and stream-out.
• Hard stop: Any VDD-to-VSS short, or LVS FAIL with 1,868 of 1,870 failed equivalences traced to one merged supply net.

What The Interviewer Is Testing

• Does the candidate know which failure types come from routing and which from cell data?
• Separating the ICC2 routing check from signoff LVS in IC Validator.
• Whether they look for one root-cause short before reading thousands of messages.

Follow-up Question & Model Response

"How would you tell whether an LVS failure is a routing problem or a library problem?"

Candidate Model Response: I would first run check_lvs (ICC2) on the same database. If it shows a short or open that matches the failing nets, it is routing. If routing checks are clean and cell.LVS_ERRORS (ICV) points at devices inside a standard cell or macro, it is almost always a view or version problem, such as the wrong GDS merged at stream-out. A device count mismatch confined to one cell type is the strongest sign of a library issue.