LVS in VLSI: Layout vs Schematic Checks, Errors and Debug

A block can meet timing, pass every DRC and still be wrong: a signal that should reach a flop stops at a missing via, or two nets touch in a crowded channel. LVS (Layout Versus Schematic) catches this. It pulls a netlist out of the final layout and checks that it matches the netlist you meant to build. LVS is one of the main physical verification sign-off checks, and a clean LVS report is needed before tapeout.

This guide covers LVS for physical design engineers in digital place-and-route (P&R) flows: inputs, extraction, comparison, reports, common errors and a debug order. The worked examples are illustrative: the numbers show the method and are not taken from any foundry, library or project. Rule decks, layer names and device recognition rules come from your PDK and are not shown here. Command snippets are simplified sketches, not complete runsets. Related reading on iVLSI: Technology DRCs in VLSI, Physical-Only Cells in VLSI, ECO in VLSI Physical Design, Antenna Effect in VLSI and Power Gating in VLSI.

What is LVS?#

LVS compares two descriptions of the same circuit:

• the layout, meaning the polygons in the GDSII or OASIS database that will be sent to the mask shop, and
• the schematic or source, meaning the reference netlist the layout is supposed to implement. For a digital block, this is the netlist written out by the P&R tool.

The check has two stages:

1. Extraction. The LVS tool reads the layout and uses the rule deck to recognise devices (transistors, diodes, resistors, capacitors) and the conductive paths between them. The result is the layout netlist.
2. Comparison. The tool compares the layout netlist with the source netlist. It reports every mismatch in nets, devices, instances, ports and device properties.

If the two netlists are equivalent, the report says the design matches (most tools print something like CORRECT). If not, you get a list of discrepancies to debug.

What LVS does not check#

LVS only checks connectivity and devices. It does not check timing or logic function (simulation and formal equivalence cover those), manufacturing rules (DRC) or parasitics (RC extraction). Electrical rule checks (ERC) often run in the same job as LVS but are reported separately:

Where LVS sits in the physical design flow#

In a digital flow, LVS is part of physical verification after routing:

1. Finish routing, metal fill and ECOs.
2. Write out the GDSII/OASIS and a netlist with power and ground connections; merge in cell, IP and macro layouts.
3. Run DRC, antenna, LVS and ERC with the sign-off decks.
4. Fix in the P&R database and rerun until clean.

Most teams also run LVS early on a trial database to prove the setup (netlist options, GDS merge list, power names), and run the P&R tool's own connectivity and PG checks before every stream-out. Every ECO, including a small metal-only fix, needs a fresh LVS run, because a single missing via is enough to break the match.

Inputs a P&R flow must supply#

Many LVS failures in digital flows are input problems, not real layout errors. Check these four inputs first.

1. The layout database. The P&R GDS usually holds routing and cell references; the real cell layouts come from the library and macro GDS merged in at stream-out. A missing or outdated cell GDS shows up as missing devices and opens.

2. The source netlist. The P&R tool writes a Verilog netlist. For LVS it must:

• include power and ground connections on every cell (a "physical" or "PG" netlist), because the layout has real power rails;
• treat physical-only cells consistently. Cells with devices, such as decap cells and antenna diode cells, must appear in the netlist or be handled by the deck. Cells with no devices and no pins, such as most fillers, are usually left out. See Physical-Only Cells in VLSI;
• use the same top cell name and port names as the layout.

The LVS tool usually wants SPICE rather than Verilog, so the Verilog is converted (Calibre's v2lvs utility is one example) and combined with the library's transistor-level cell netlists (often supplied as CDL or SPICE files).

3. The rule deck. The foundry deck defines device recognition, layer connectivity, how labels name nets and which device parameters are compared. You don't edit its rules, but you set the options it exposes, such as power names, black-box cells and case sensitivity.

4. Run options. Top cell name, the cell correspondence list for hierarchical runs (often called an hcell list) and power net names. Be careful with virtual connections, which let disconnected pieces of a net with the same label count as connected: they can hide a real open at sign-off.

How extraction works#

Extraction rebuilds the circuit from polygons:

• Device recognition. The deck derives device layers from drawn layers. In a simple planar CMOS view, a MOS gate is where poly crosses active diffusion, implant and well layers decide NMOS or PMOS, and width and length are measured from the geometry. FinFET and GAA decks are more complex, but the idea is the same.
• Connectivity. Shapes on the same layer that touch form one conductor. Vias and contacts connect layers where they overlap the shapes above and below. The deck also defines how wells and substrate connect to tap regions.
• Net naming. Text labels placed on a conductive layer give the net under them a name. Port labels at the top level matter most, because they anchor the comparison.
• Hierarchy. Hierarchical extraction keeps each cell as a subcircuit, which makes runs faster and reports easier to read.

How comparison works#

LVS compares netlists as graphs: devices and subcircuits are nodes, and nets join them. The comparison is driven by topology, not names. Net names and labels help resolve ambiguity and anchor ports, but two netlists with completely different internal net names can still match.

Points worth knowing:

• Bottom-up hierarchy. Hierarchical comparison matches leaf cells first, then the cells that use them. If a lower cell does not match, its parents may be skipped or reported with misleading errors. Fix from the bottom up.
• Device reduction. Parallel transistors (fingers or multipliers) are usually combined into one device with the total width before comparison. Series devices and passive networks can also be reduced, depending on the deck.
• Logically equivalent pins. The inputs of a NAND gate are logically swappable but physically different. Decks and tools let you declare such pins equivalent so the comparison can swap them.
• Ambiguity. Very regular structures such as clock trees and memory arrays can look symmetric to the matcher; good port labels and correct power nets help it.

Reading an LVS report#

A typical report starts with an overall result and a summary table, then lists the discrepancies. The summary compares counts of ports, nets and instances (or devices) between layout and source.

Error types you will meet:

Worked example A: why net counts can mislead (illustrative)#

A block's LVS summary shows:

The layout has 3 fewer nets. The tempting conclusion is "three shorts", but each short merges two nets into one (−1 net) and each open splits one net into two (+1 net). The discrepancy list in this example actually contains 4 shorts and 1 open:

net difference = −4 (shorts) + 1 (open) = −3

The summary hides the open completely. The rule: use counts to sense the size of the problem, and read the discrepancy list to find the problems. Equal counts don't mean a clean run, because a short and an open together cancel out.

Worked example B: one power short, thousands of errors (illustrative)#

After a late ECO, LVS reports more than 20,000 discrepancies: nets with unexpected connections, unmatched instances and a merged net named VDD that also contains every VSS pin.

It is one fault: with power and ground shorted, the matcher cannot tell the supplies apart, so almost every cell looks wrong.

Debug steps:

1. Spot the merged supply net in the report. Most tools flag a short between two labelled nets with the label names, such as VDD and VSS.
2. Run the tool's short-isolation or short-path feature, or highlight the shortest path between a VDD label and a VSS label in the layout viewer.
3. The path ends at a single via that the ECO dropped where a VDD strap crosses a VSS strap.
4. Remove the via in the P&R database, write out again and rerun.

The rerun drops to a handful of real issues. Fix power shorts first. Then fix signal shorts, then opens. Everything else in the report may be noise until the supplies are clean. The KLayout manual makes a related point: a failing compare often leaves the power nets unmapped, which then stops good parts of the circuit from matching.

Worked example C: labels in a power-gated block (illustrative)#

A block has an always-on supply VDD and a switched supply VDDV behind header switches (see Power Gating in VLSI). LVS reports a short between VDD and VDDV, but tracing the geometry finds no metal joining them.

The cause is a text label. A top-level VDD label was placed on a strap that, after a floorplan change, belongs to the VDDV grid. The extractor sees two different names on one connected net and reports it as a short, or names the net wrongly, depending on the deck.

Fix: move or regenerate the labels from the P&R tool so each lands on its own supply's shapes, and check that pin labels are on the text layer the deck expects. The lesson: when a short makes no geometric sense, check the labels before re-routing anything.

A related issue is well connectivity: if cells from two supply domains share one continuous n-well, the deck may report a soft-connection conflict. The fix is in floorplan and placement (domain spacing, well breaks, taps), not the netlist. Level Shifters in VLSI covers the domain boundary rules.

Hierarchical LVS, macros and black boxes#

Chip-level and large block LVS is run hierarchically:

• Each standard cell and macro in the layout is paired with a subcircuit in the source netlist, by name or through an hcell list.
• Hard IP that the vendor has already verified (SRAMs, PLLs, I/O pads) is often run as a black box (also called an abstract). The tool checks the pins and the connections to them, and ignores the inside. KLayout calls these abstract circuits.
• Black-boxing is a deliberate sign-off decision. It must match how the IP vendor qualified the macro, and the macro's own LVS must be clean.

Common hierarchical problems: GDS cell names that differ from netlist module names, bus-bit format mismatches (D[3] vs D<3>), and block pins that don't line up with parent routing, which show up as opens at the boundary.

Common LVS problems in digital flows and their fixes#

Debug flowchart: fixing an LVS failure#

When LVS fails, work in this order. Each step removes noise that would mislead the next one.

1. Are the inputs right? Top cell, GDS merge list, PG netlist, deck version and options.
2. Extraction or label errors? Duplicate labels, labels off any shape, illegal devices.
3. Power or ground shorts? Trace the short path, remove the bridge, rerun.
4. Signal shorts? Trace each merged net to the touching shapes, stray via or fill.
5. Opens? Walk each split net layer by layer to the break; a cluster of opens usually has one cause.
6. Missing or extra instances? Missing cell GDS, physical cells left out of the netlist, deleted spare cells.
7. Port or property mismatches? Labels, bus naming, cell variants.
8. Rerun LVS and ERC until both are clean, with no forced net equivalences left in the final run.

A note on tool hints#

LVS tools let you give the matcher hints. The open-source KLayout LVS documents several:

# KLayout LVS hints (sketch; see the KLayout LVS Compare manual) same_nets("LOGIC", "VDD", "VDD:P") # declare two nets identical (debug only) equivalent_pins("NAND_GATE", "A", "B") # logically swappable inputs tolerance("NMOS", "L", 0.0, 0.01) # 1% relative tolerance on L compare flag_missing_ports # report top pins whose labels don't match

The KLayout manual warns that a power-net equivalence like the first line should not stay in the script for final verification, because it can mask real errors. Commercial tools have their own forms of these options, and the same caution applies. Netgen, the open-source LVS tool from the Magic/OpenCircuitDesign suite, works on the same netlist comparison principle.

Interview Q&As#

Q1. What is LVS and why is it needed? LVS extracts a netlist from the layout and compares it with the reference netlist. It proves that the drawn shapes form the intended circuit, so shorts, opens and missing devices are caught before tapeout.

Q2. What are the two main steps of LVS? Extraction, which builds devices and connectivity from layout layers using the rule deck, and comparison, which matches the layout netlist against the source netlist and reports discrepancies.

Q3. Which do you fix first, shorts or opens? Why? Shorts first, starting with power-ground shorts. One short can make thousands of unrelated nets and instances fail to match. Opens are usually local.

Q4. Can LVS pass while net counts differ, or fail while counts match? Counts can match while LVS fails, because a short (−1 net) and an open (+1 net) cancel out. LVS cannot pass with a real count mismatch. Always read the discrepancy list.

Q5. What is a label (text) short? Two different net labels end up on one connected layout net, for example a VDD label on a VDDV strap. The tool reports a short with no metal bridge. Fix the label, not the routing.

Q6. Why must the LVS netlist contain decap cells but usually not fillers? Decap cells contain transistors that the extractor will find, so the source must have them. Most fillers have no devices and no pins, so they add nothing to the comparison.

For more practice, see Routing Interview Questions and Answers.

FAQ#

Does a clean LVS mean the chip will work? No. It means the layout matches the netlist. Function, timing, power integrity and reliability are checked by other sign-off steps such as STA, IR drop analysis and electromigration checks.

Why do digital designers need LVS if the router "knows" the connectivity? The router works on abstracts (LEF), not on final mask shapes. Merging real cell GDS, fill, labels, manual edits and IP can all break connectivity in ways the P&R database never sees. LVS checks the actual shapes that go to the mask shop.

Summary#

• LVS extracts a netlist from the layout and compares it with the source netlist. It catches shorts, opens, missing or extra devices and port or property mismatches.
• In P&R flows, many failures are setup problems: a netlist without PG pins, missing cell GDS, physical cells handled inconsistently, labels and naming.
• Fix in order: setup, extraction and labels, power shorts, signal shorts, opens, then device and port issues.
• Run LVS early to prove the setup, and rerun after every ECO.

References#

• KLayout documentation, "Layout vs. Schematic (LVS) Overview": https://www.klayout.de/doc/manual/lvs_overview.html
• KLayout documentation, "LVS Compare": https://www.klayout.de/doc/manual/lvs_compare.html
• Netgen netlist comparison (LVS) tool, OpenCircuitDesign: http://opencircuitdesign.com/netgen/
• Siemens Calibre blog, "From translator to powerhouse: Calibre V2LVS second generation redefines LVS verification" (2025): https://blogs.sw.siemens.com/calibre/2025/10/16/from-translator-to-powerhouse-calibre-v2lvs-second-generation-redefines-lvs-verification/
• Related iVLSI posts: Physical Design Flow, Synthesized Netlist, Physical Library (LEF), Design Exchange Format (DEF), Double Patterning in VLSI, Power Planning in VLSI