LVS Debugging Methodology
A systematic way to trace shorts, opens, and mismatches
LVS rarely passes on the first run, and reading the report well is a senior skill. The discipline is to fix errors in the right order, because one root cause often explodes into dozens of downstream mismatches. Chasing symptoms instead of the source is how engineers lose days on a check that should take an afternoon.
Fix in the right order
Always resolve extraction and connectivity problems before device or net-count mismatches. A single short or open changes the connectivity that the comparison engine sees, so it can rename or fail to match many nets at once. Clear the shorts first, then the opens, then look at what mismatches remain. Most of them will already be gone.
| Symptom | Likely root cause | Where to look |
|---|---|---|
| Two named nets merged | Short: touching metal or stray via | Extracted short report, layout marker |
| One net split in two | Open: missing via or gap in metal | Net highlight, layer-by-layer trace |
| Property mismatch | Wrong W/L, fingers, or multiplier | Device parameters, schematic vs layout |
| Unmatched instances | Missing device or extra dummy | Device count summary |
| Port mismatch | Pin label missing or on wrong layer | Text / label layer, pin geometry |
Tracing a short
A short is the most common and most disruptive error: two nets that should be separate are electrically joined. The tool reports them as a single merged net and usually highlights the offending geometry. The fastest trace is to highlight the shorted net in the layout and follow it until two signals that should not meet are seen touching, often a metal overlap, a misplaced via, or two pins drawn on the same track. Foundry decks frequently dump a short-isolation path that names the exact polygons forming the bridge.
Tracing an open
An open is the opposite: one schematic net appears as two or more disconnected pieces in the layout, so the comparison cannot match either piece to the original. The usual culprit is a missing via between layers or a hairline gap in metal. Highlight the net, then walk it layer by layer at each transition. Wherever the highlight stops while the schematic says it should continue is the break.
Parameter and device mismatches
Once connectivity is clean, remaining errors are usually device-level. A property mismatch means the topology matched but a parameter did not: a transistor drawn with the wrong width, the wrong number of fingers, or a different multiplier than the schematic. Read the reported W/L and m values side by side. Extra or missing devices often trace to dummy or filler transistors that the extraction rules did or did not expect.
# Reading an LVS comparison summary (engine-neutral)
# Nets: layout 1042 source 1043 -> one net short or open
# Instances: layout 318 source 318 -> device counts agree
#
# Mismatch:
# net "vdd_core" merged with "vss_core" <- SHORT, fix first
# net "clk" has 2 segments in layout <- OPEN, fix next
# M14 W=0.5u(layout) W=1.0u(source) <- parameter, fix last
#
# Method: clear shorts -> clear opens -> re-run -> resolve device propsState the golden order out loud in interviews: shorts first, then opens, then device and property mismatches. Explaining that one short can cascade into many false net mismatches is exactly the reasoning that separates someone who has debugged real LVS from someone who has only read about it.
Do not blindly trust the larger error count: hundreds of net mismatches frequently collapse to one or two physical shorts. Re-run LVS after every connectivity fix instead of trying to interpret a stale report, or you will waste time chasing mismatches that no longer exist.