What does LVS actually compare?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
LVS compares two netlists: the reference netlist the design was built from and a netlist IC Validator extracts from the layout geometry. It matches devices and their types and properties, how the device terminals connect into nets, and the ports at the top and at each equivalence point. It does not look at timing or rule spacing, only whether the layout is the same circuit.
Technical Explanation
- The reference side is usually a SPICE or Verilog netlist of the block, with standard cells and macros expanded down to the level the LVS runset expects. On the command line it is supplied with
-s(ICV) and its format with-sf(ICV), which accepts SPICE, VERILOG or ICV. - The layout side comes from extraction. The runset recognises devices from layer combinations, for example a gate where poly crosses diffusion, and builds nets by following connected metal, vias and contacts. Text labels on pins give extracted nets their names.
- Devices are matched by type and by properties the runset asks for, such as transistor width and length. A missing device, an extra device or a device with the wrong size is an LVS error even if the connectivity looks right.
- Connectivity is matched structurally, not by name. The comparison finds nets whose connected device terminals match on both sides. Names help anchor the match at ports, but two nets swapped by mistake can still be detected because their connections differ.
- Ports matter. A top-level pin with the wrong label, or two pins shorted together, shows up as a port mismatch. The
compare()(ICV) function performs the comparison and writescell.LVS_ERRORS(ICV), the starting point for debug. - Hierarchy is handled through equivalence points: pairs of cells that exist in both netlists and can be compared once and reused. The
cell.RESULTS(ICV) LVS summary reports how many equivalences were checked, passed and failed. - Extraction can itself report problems before the compare starts, such as a text label that lands on no shape or shapes that cannot be classified as a device. For an LVS run,
cell.RESULTS(ICV) reports these on its second header line,DRC and Extraction Results: CLEAN | NOT CLEAN(ICV), and they should be cleared first because they distort the compare. - LVS says nothing about whether a circuit works. If the reference netlist has a bug, LVS confirms the layout faithfully contains the same bug.
Common Mistake
The Trap: Running LVS against a reference netlist written out before the last functional ECO. The layout contains two new buffers and a rewired enable, so LVS fails with dozens of mismatches, and the engineer spends a day "debugging" layout that is actually correct. Always regenerate the reference netlist from the same database state as the GDS, and record the netlist and GDS timestamps next to the LVS result so anyone rerunning it can confirm the pair belongs together. A mismatched pair is one of the most common causes of a false LVS failure late in a project.
Follow-up Question & Model Response
"Why can LVS still find a problem when every net name in the layout matches the schematic?"
Candidate Model Response: Because LVS matches structure, not only names. If two nets carry the right labels but a via connects one of them to a third net, the extracted device connections no longer match the reference, and the comparison fails. Likewise a device with the wrong width fails on properties. Names are anchors that make the match faster and error reports readable. The proof comes from the topology and device comparison.
Practical Example
Tapeout Scenario: A small block has 48,000 standard cells expanded to about 610,000 transistors in the reference netlist (illustrative). Extraction from the layout finds 610,002 transistors. The two extra devices sit inside a decap cell whose GDS version differs from the one assumed by the reference. cell.LVS_ERRORS (ICV) lists the decap as a failed equivalence with two unmatched devices. Updating the reference to the matching cell version gives LVS Compare Results: PASS (ICV) with all equivalences passing. No layout change was needed; the error was in what the layout was being compared against.
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