diff --git a/src/lay/lay/doc/manual/lvs.xml b/src/lay/lay/doc/manual/lvs.xml
index 104fc10a8..74fb8a24a 100644
--- a/src/lay/lay/doc/manual/lvs.xml
+++ b/src/lay/lay/doc/manual/lvs.xml
@@ -19,13 +19,7 @@
A reference for the functions and objects available for LVS scripts can be found here: .
diff --git a/src/lay/lay/doc/manual/lvs_compare.xml b/src/lay/lay/doc/manual/lvs_compare.xml index 185449fa7..221bee1f6 100644 --- a/src/lay/lay/doc/manual/lvs_compare.xml +++ b/src/lay/lay/doc/manual/lvs_compare.xml @@ -65,6 +65,11 @@same_circuits("CIRCUIT_IN_LAYOUT", "CIRCUIT_IN_SCHEMATIC")
+ + Declaring circuits as 'same' means they will still be compared. The function is just + a hint where to look for the compare target. +
+@@ -120,4 +125,60 @@ same_device_classes("NMOS_IN_LAYOUT", "NMOS_IN_SCHEMATIC")
max_caps(1e-16)+
+ The coarse flow of the netlist compare algorithm is this: +
+ +foreach circuit bottom up: + if matching circuit found in reference netlist: + if all subcircuits have been matched and pin matching has been established for them: + compare net graph locally from this circuit + else: + skip circuit with warning + else: + issue a circuit mismatch error+ +
+ A consequence of this flow is that the compare will stop treating parent circuits when + one circuit's pins can't be matched to pins from the corresponding reference circuit + or the corresponding circuit can't be found in the reference netlist. This behaviour + fosters a bottom-up debugging approach: first fix the issues in subcircuits, then + proceed to the parent circuits. +
+ ++ The local net graph compare algorithm is a backtracking algorithm with + hinting through topological net classification. Topological net classification + is based on nearest-net neighborhood. The following image illustrates this: +
+ +
+
+
+ Here the IN net's neighborhood is VDD via a traversal of gate to source/drain + over M1, to OUT via a twofold traversal of gate to source/drain over M1 and M2 + and to VSS via another single traversal of gate to source/drain over M2. + This uniquely identifies IN in this simple circuit. In effect, OUT, VDD and VSS + can be identified uniquely because their transitions from the IN net are + unambigously identifying them. The topological neighborhood is a simple metrics + which allows identifying matching nets from two netlists and deducing further relations. +
+ ++ In big netlists, the algorithm will first try to match nets unambigously according + to their neighborhood metrics and register them as paired nets. + Such pairs often allow deducing further matching pairs. This deduction is + continued until all non-ambiguous pairing options are exhausted. + For resolving ambiguities, backtracking is employed: + the algorithm proposes a match and tentatively proceeds with this assumption. + If this execution path leads to a mismatch or logical contradiction, + the algorith will go back to the beginning and restart with a + new proposal. Backtracking is usually required mainly to match networks + with a high symmetry such as clock trees. +
+ diff --git a/src/lay/lay/doc/manual/lvs_tweaks.xml b/src/lay/lay/doc/manual/lvs_tweaks.xml index 783cd6b9e..d892afb3e 100644 --- a/src/lay/lay/doc/manual/lvs_tweaks.xml +++ b/src/lay/lay/doc/manual/lvs_tweaks.xml @@ -3,13 +3,140 @@+ Netlist tweaking is important to standardize netlists. Without tweaking, + the extracted netlist may contain elements that are redundant or + don't match anything found in the schematic.
+
+ Netlist tweaks are applied on the extracted
+ Netlist tweaks can also be applied to the schematic netlist. For example to flatten away + a model subcircuit called "NMOS", use this expression: +
+ +schematic.flatten_circuit("NMOS")
+
+ + Circuits extracted don't have pins on the top hierarchy level as the + extractor cannot figure out where to connect to this circuit. + The compare function does not try to match pins in this case. + But to gain a useful extracted netlists, pins are required. + Without pins, a circuit can't be embedded in a testbench for + example. +
+ +
+ KLayout offers a function to create top-level pins using
+ a simple heuristics: for every named (i.e. labelled) net in the top level
+ circuit a pin will be created (
netlist.make_top_level_pins+ +
+ Combining devices is important for devices which are not + represented as coherent entities in the layout. Examples are: +
+ +
+ In all these cases, the schematic usually summarizes these devices
+ into a single one with lumped parameter values (total resistance, capacitance,
+ transistor width). This creates a discrepancy which "device combination"
+ avoids. "Device combination" is a step in which devices are identified which
+ can be combined into single devices (such as serial or parallel resistors and
+ capacitors). To run device combination, use
netlist.combine_devices+ +
+ The combination of serial devices might leave floating nets (the net connecting the
+ devices originally. These nets can be removed with
+ It's recommended to run "make_toplevel_pins" and "purge" before this step (see below). +
+ ++ It's often required to flatten circuits that do not represent a specific level of organisation but + act as a wrapper to something else. In layouts, devices are often implemented as PCells and + appear as specific cells for no other reason than being implemented in a subcell. The same + might happen for schematic subcircuits which wrap a device. "Flattening" means that a circuit + is removed and it's contents are integrated into the calling circuits. +
+ ++ To flatten a circuit from the extracted netlist use +
+ +netlist.flatten_circuit("CIRCUIT_NAME")
+
+ + Extracted netlists often contain elements without a functional + aspect: via cells for example generate subcircuits with a single pin and + no device. Isolated metal islands (letters, logos, fill/planarisation + patches) will create floating nets etc. Two methods are available to + purge those elements. +
+ +
+
netlist.purge +netlist.purge_nets+ +
+
netlist.simplify+