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. +

+

Device class equivalence hint

@@ -120,4 +125,60 @@ same_device_classes("NMOS_IN_LAYOUT", "NMOS_IN_SCHEMATIC")

max_caps(1e-16)
+

How the compare algorithm works

+ +

+ 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 @@ - LVS Tweaks + LVS Netlist Tweaks - +

+ 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 object. + This can be obtained with the netlist function. + This function will extract the netlist if not done already. +

+ +

+ 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")
+ +

Top level pin generation

+ +

+ 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
+ +

Device combination

+ +

+ Combining devices is important for devices which are not + represented as coherent entities in the layout. Examples are: +

+ +
    +
  • Fingered MOS transistors: MOS transistors with a large width + are often split into multiple pieces to reduce the parasitic gate and + diffusion resistances and capacitances. In the layout this is equivalent + to multiple parallel transistors. +
  • +
  • Serial resistors: Large resistors are often separated into + stripes which are then connected in a meander structure. From the device + perspective such resistors consist of several resistors connected in + series. +
  • +
  • Array capacitors: Large capacitors are often split into + smaller ones which are arranged in an array and connected in parallel. + This helps controlling the parasitic series resistances and inductances + and avoids manufacturing issues. +
  • +
+ +

+ 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 . + See also , which is wrapper for several + methods related to netlist normalization. +

+ +

+ It's recommended to run "make_toplevel_pins" and "purge" before this step (see below). +

+ +

Circuit flattening (elimination)

+ +

+ 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")
+ +

Purging (elimination of redundancy)

+ +

+ 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. +

+ +

+ will remove all floating nets, + all circuits without devices or subcircuits. + will only purge floating nets. + Floating nets are nets which don't connect to any device or subcircuit. +

+ +
netlist.purge
+netlist.purge_nets
+ +

Normalization wrapper (simplification)

+ +

+ is a wrapper for "make_top_level_pins", + "combine_devices" and "purge" in the recommended order: +

+ +
netlist.simplify
+
diff --git a/src/lay/lay/doc/manual/net_graph.png b/src/lay/lay/doc/manual/net_graph.png new file mode 100644 index 000000000..fc581b922 Binary files /dev/null and b/src/lay/lay/doc/manual/net_graph.png differ diff --git a/src/lay/lay/layHelpResources.qrc b/src/lay/lay/layHelpResources.qrc index 0d977fed5..22848c6aa 100644 --- a/src/lay/lay/layHelpResources.qrc +++ b/src/lay/lay/layHelpResources.qrc @@ -186,6 +186,7 @@ doc/manual/inv_with_diodes.png doc/manual/inv_schematic.png doc/manual/inv_schematic2.png + doc/manual/net_graph.png doc/manual/bjt3_schematic.png doc/manual/bjt4_schematic.png doc/manual/mos3_schematic.png