+Some functions are available on global level and can be used without any object. +Most of them are convenience functions that basically act on some default object +or provide function-like alternatives for the methods. +
+LVS is built upon DRC. So all functions available in DRC are also available +in LVS. In LVS, DRC functions are used to derive functional layers from original +layers or specification of the layout source. +
+For more details about the DRC functions see DRC::global. +
+Usage:
++See Netter#compare for a description of that function. +
+Usage:
++See Netter#equivalent_pins for a description of that function. +
+Usage:
++See Netter#max_res for a description of that function. +
+Usage:
++See Netter#min_caps for a description of that function. +
+Usage:
++See Netter for more details +
+Usage:
++After the comparison step, the LVS database will be shown +in the netlist database browser in a cross-reference view. +If a filename is given, the LVS database is also written to +this file. +
+If this method is called together with report_netlist and two files each, two +files can be generated - one for the extracted netlist (L2N database) and one for the +LVS database. However, report_netlist will only write the extracted netlist +while report_lvs will write the LVS database which also includes the +extracted netlist. +
+report_lvs is only effective if a comparison step is included. +
+Usage:
++See Netter#same_circuits for a description of that function. +
+Usage:
++See Netter#same_device_classes for a description of that function. +
+Usage:
++See Netter#same_nets for a description of that function. +
+Usage:
++See Netter#schematic for a description of that function. +
++The Netter object provides services related to network extraction +from a layout plus comparison against a reference netlist. +Similar to the DRC DRC::Netter (which lacks the compare ability), the +relevant method of this object are available as global functions too +where they act on a default incarnation. Usually it's not required +to instantiate a Netter object explicitly. +
+The LVS Netter object inherits all methods of the DRC::Netter. +
+An individual netter object can be created, if the netter results +need to be kept for multiple extractions. If you really need +a Netter object, use the global global#netter function: +
+
+# create a new Netter object:
+nx = netter
+
+# build connectivity
+nx.connect(poly, contact)
+...
+
+# read the reference netlist
+nx.schematic("reference.cir")
+
+# configure the netlist compare
+nx.same_circuits("A", "B")
+...
+
+# runs the compare
+if ! nx.compare
+puts("no equivalence!")
+end
+
+
+Usage:
++Before using this method, a schematic netlist has to be loaded with schematic. +The compare can be configured in more details using same_nets, same_circuits, +same_device_classes and equivalent_pins. +
+This method will return true, if the netlists are equivalent and false +otherwise. +
+Usage:
++This method will mark the given pins as equivalent. This gives the compare algorithm +more degrees of freedom when establishing net correspondence. Typically this method +is used to declare inputs from gates are equivalent where are are logically, but not +physically (e.g. in a CMOS NAND gate): +
+
+netter.equivalent_pins("NAND2", "A", "B")
+
++Before this method can be used, a schematic netlist needs to be loaded with +schematic. +
+Usage:
+
+The
Usage:
++After using this method, the netlist compare will ignore resistor devices +with a resistance value above the given threshold (in Farad). +
+Usage:
++After using this method, the netlist compare will ignore capacitance devices +with a capacitance values below the given threshold (in Farad). +
+Usage:
++This method will force an equivalence between the two circuits. +By default, circuits are identified by name. If names are different, this +method allows establishing an explicit correspondence. +
+Before this method can be used, a schematic netlist needs to be loaded with +schematic. +
+Usage:
++This method will force an equivalence between the two device classes. +Device classes are also known as "models". +By default, device classes are identified by name. If names are different, this +method allows establishing an explicit correspondence. +
+Before this method can be used, a schematic netlist needs to be loaded with +schematic. +
+Usage:
++This method will force an equivalence between the net_a and net_b from circuit_a +and circuit_b (circuit in the three-argument form is for both circuit_a and circuit_b). +Circuit and nets are string giving a circuit and net by name. +After using this function, the compare algorithm will consider these nets equivalent. +Use this method to provide hints for the comparer in cases which are difficult to +resolve otherwise. +
+Before this method can be used, a schematic netlist needs to be loaded with +schematic. +
+Usage:
+
+If a filename is given (first two forms), the netlist is read from the given file.
+If no reader is provided, Spice format will be assumed. The reader object is a
+
+Alternatively, a
+ LVS is a verification step which checks whether a layout matches the circuit + from the schematic. The LVS feature is described in the following topic chapters: +
+ +A reference for the functions and objects available for LVS scripts can be found here: .
+ ++ 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 extension, they are still useful for implementing Antenna checks + for example. +
+ ++ 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 . For + an introduction about how to work with DRC scripts see . +
+ ++ 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 . +
+ ++ 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: +
+ +The net tracing function allows tracing of a net by detecting touching shapes that together form a conductive region. It features specification of a stack of metal (or in general "conductive") layers optionally connected through @@ -16,8 +18,10 @@ active area region.
+- The algorithm is intended for extracting single nets and employs an incremental extraction approach. Therefore + This algorithm is intended for extracting single nets and employs an incremental extraction approach. Therefore extraction of a single small net is comparatively fast while extraction of large nets such as power nets is considerably slower compared to hierarchical LVS tools currently.
@@ -61,5 +65,53 @@ is changed to fit the net. ++ This algorithm is borrowed from the LVS feature, where the scenario is extended by device + recognition and netlist formation. In the context of the net tracer, nets consist of the + connected shapes but don't attach to devices. As LVS extracts all nets in one sweep, using + this feature in the net tracer will deliver all nets at once. Although this is a richer + information output, the tracing of all nets is typically faster then tracing a single, big + net such as power nets. The LVS net extractor also supports hierarchical processing which + gives a considerable performance improvement and more compact net representations. +
+ ++ To extract all nets, use "Trace All Nets" from the "Tools" menu. It will start extracting + the nets immediately. It will take the connectivity definition from the standard, single-net + net tracer. You can edit this layer stack either from the single net tracer UI, from the technology + manager or "Edit Layer Stack" from the "Tools" menu. +
+ ++ After the net tracer has finished, the netlist browser dialog opens. In this dialog you + can: +
+ ++ Extracted nets are written and read in a KLayout-specific format called "L2N" ("layout to netlist"). + This format contains both the nets and the shapes that make up a net. This way, the traced + nets can be saved and retrieved later. +
+