KLayout Documentation (Qt 5): Main Index » KLayout User Manual » Layout vs. Schematic (LVS) » Layout vs. Schematic (LVS) Overview

Layout vs. Schematic (LVS) Overview

• Basic usage of LVS scripts
• KLayout's LVS implementation
• Terminology

Basic usage of LVS scripts

Starting with version 0.26, KLayout supports LVS as a built-in feature. LVS is an important step in the verification of a layout: it ensures the drawn circuit matches the desired schematic.

The basic functionality is simply to analyze the input layout and derive a netlist from this. Then compare this netlist against a reference netlist (schematic). If both netlist are equivalent, the circuit is likely to work in the intended fashion.

Beside the layout, a LVS script will also need a schematic netlist. Currently, KLayout can read SPICE-format netlists. The reader can be configured to some extent, so the hope is that a useful range of SPICE netlists can be digested.

While the basic idea is simple, the details become pretty complex. This documentation tries to cover the solutions KLayout offers to implement LVS as well as the constraints imposed by this process.

KLayout's LVS is integrated into the Macro Development IDE the same way as DRC scripts. In fact, LVS is an add-on to DRC scripts. All DRC functions are available within LVS scripts. Netlist extraction is performed in the DRC framework which was given the ability to recognize devices and connections and turn them into a netlist. Although DRC does not really benefit from these extensions, they are still useful for implementing Antenna checks for example. As it happens, the majority of features required for LVS is documented in the DRC Reference, while the few add-ons required specifically for LVS are documented in LVS Reference.

LVS scripts are created, edited and debugged in the Macro Editor IDE. They are managed in the "LVS" tab. For more details about the IDE, see About Macro Development. For an introduction about how to work with DRC scripts see Design Rule Checks (DRC) Basics.

LVS scripts carry the ".lylvs" extension for the XML form (in analogy to ".lydrc" for DRC) and ".lvs" for the plain text form (same as ".drc"). Like DRC scripts, LVS scripts can be executed standalone in batch mode like DRC scripts. See "Using KLayout as a standalone DRC engine" in Design Rule Checks (DRC) Basics.

KLayout's LVS implementation

The LVS implementation inside KLayout is designed to be highly flexible in terms of connectivity, device recognition and input/output channels. Here are some highlights:

• Agnostic approach: KLayout tries to make as few assumptions as possible. It does not require labels (although they are helpful), a specific hierarchy, specific cell names or specific geometries. Netlist extraction is done purely from the polygons of the layout. Labels and the cell hierarchy add merely useful hints which simplify debugging and pin assignment, but no strict requirement.
• Hierarchical analysis: KLayout got a hierarchical layout processing engine to support hierarchical LVS. Hierarchical processing means that boolean operations happen inside the local cell environment as far as possible. As a consequence, devices are recognized inside their layout cell and layout cells are turned into respective subcircuits in the netlist. The netlist compare will benefit as it is able follow the circuit hierarchy. This is more efficient and gives better debugging information in case of mismatches. As a positive side effect of hierarchical layout processing the runtimes for some boolean and other operations is significantly reduced in most cases.
• Hierarchically stable: KLayout won't modify the layout's hierarchy nor will it introduce variants - at least for boolean and some other operations. This way, matching between layout and schematic hierarchy is maintained even after hierarchical DRC operations. Variants are introduced only for some anisotropic operations, the grid snap method and some other features which require differentiation of cells in terms of location and orientation.
• Flexible engine: The netlist formation engine is highly flexible with respect to device recognition and connectivity extraction. First, almost all DRC features can be used to derive intermediate layers for device formation and connectivity extraction. Second, the device recognition can be scripted to implement custom device extractors. Five built-in device extractors are available for MOS and bipolar transistors, resistors, capacitors and diodes.
• Flexible I/O: Netlists are KLayout object trees and their components (nets, devices, circuits, subcircuits ...) are fully mapped to script objects (for the main class see Netlist in the API documentation). Netlists can therefore be analyzed and manipulated within LVS scripts or in other contexts. It should be possible to fully script readers and writers for custom formats. Netlists plus the corresponding layout elements (sometimes called "annotated layout") can be persisted in a KLayout-specific, yet open format. SPICE format is available to read and write pure netlist information. The SPICE reader and writer is customizable through delegate classes which allow tailoring of the way devices are read and written.
• User interface integration: KLayout offers a browser for the netlist extraction results and LVS reports (cross-reference, errors).

Terminology

KLayout employs a specific terminology which is explained here:

• Circuit: A graph of connected elements as there are: devices, pins and subcircuits. The nodes of the graph are the nets connecting at least two elements. If derived from a layout, a circuit corresponds to a specific layout cell.
• Abstract circuits: Abstract circuits are circuits which are cleared from their inner structure. Such circuits don't have nets and define pins only. Abstract circuits are basically "black boxes" and LVS is required to consider their inner structure as "don't care". Abstract circuits are useful to reduce the netlist complexity by taking out big IP blocks verified separately (e.g. RAM blocks).
• Pin: A point at which a circuit makes a connection to the outside. Circuits can embed other circuits as "subcircuits". Nets connecting to the pins of these subcircuits will propagate into the subcircuit and connect further elements there. Pins are usually attached to one net - in some cases, pins can be unattached (circuits abstracts). Pins can be named. Upon extraction, the pin name is derived from the name of the net attached to the pin.
• Subcircuit: A circuit embedded into another circuit. One circuit can be used multiple times, hence many subcircuits can reference the same circuit. If derived from a layout, a subcircuit corresponds to a specific cell instance.
• Device: A device is a n-terminal entity describing an atomic functional unit. Devices are passive devices (resistors, capacitors) or active devices such as transistors.
• Device class: A device class is a type of device. Device classes are of a certain kind and there can be multiple classes per type. For example for MOS transistors, the kind is "MOS4" (a four-terminal MOS transistor) and there is usually "NMOS" and "PMOS" classes at least in a CMOS process. A device class typically corresponds to a model in SPICE.
• Device extraction: Device extraction is the process of detecting devices and forming links between conductive areas and the device bodies. These links will eventually form the device terminals.
• Device combination: Device combination is the process of forming single devices from combinations of multiple devices of the same class. For example, serial resistors can be combined into one. More importantly, parallel MOS transistors ("fingered" transistors) are combined into a single device. Device combination is a step explicitly requested in the LVS script.
• Terminal: A "terminal" is a pin of a device. Terminals are typically named after their function (e.g. "G" for the gate of a MOS transistor).
• Connectivity: The connectivity is a description of conductive regions in the technology stack. A layer has intra-layer and intra-layer connectivity: "Intra-layer connectivity" means that polygons on the same layer touching other polygons form a connected - i.e. conductive - region. "Inter-layer connectivity" means that two layers form a connection where their polygons overlap. The sum of these rules forms the "connectivity graph".
• Netlist: A hierarchical structure of circuits and subcircuits. A netlist typically has a top circuit from which other circuits are called through subcircuits.
• Extracted netlist: The extracted netlist is the netlist derived from the layout. Sometimes, "extracted netlist" describes the netlist enriched with parasitic elements such as resistors and capacitors derived from the wire geometries. In the context of KLayout's LVS, "extracted netlist" is the pure connectivity without parasitic elements.
• Schematic: The "schematic" is a netlist taken as reference for LVS. The "schematic" is thought of the "drawn" netlist that is turned into a layout by the physical implementation process. In LVS, the layout is turned back into the "extracted netlist" which is compared to the schematic.
• Annotated layout, Net geometry: The collection of polygons belonging to the individual nets. Each net inside a circuit is represented by a bunch of polygons representing the original wire geometry and the device terminals. As nets can propagate to subcircuits through pins, nets and therefore annotated layout carries a per-net hierarchy. The per-net hierarchy consists of the subcircuits attached to one net and the nets within these subcircuits that connect to the outer net. Subcircuits can instantiate other subcircuits, so the hierarchy may extend over many levels.
• Layout to netlist database (L2N DB): This is a data structure combining the information from the extracted netlist and the annotated layout into a single entity. The L2N database can be used to visualize nets, probe nets from known locations and perform other analysis and manipulation steps. An API for handling L2N databases is available.
• Cross reference: The cross reference is a list of matching objects from the two netlists involved in a LVS netlist compare ("pairing"). The cross-reference also lists non-matching items and inexact pairs. "Inexact pairs" are pairs of objects which do not match precisely, but still are likely to be paired. The cross reference also keeps track of the compare status - i.e. whether the netlists match and if not, where a mismatch originates from.
• LVS database: The "LVS database" is the combination of L2N database, the schematic netlist and the cross-reference. It's a complete image of the LVS results. An API is available to access the elements of the LVS database.
• Labels: "Labels" are text objects drawn in a layout to mark certain locations on certain layers with a text. Typically, labels are used to assign net names - if included in the connectivity, nets formed from such labels get a name according to the text string of the label.