* Fixed issue-1135 (LVS mismatch on parallel devices)
The fix consists of a more elaborate device identity analysis
following the topological matching. In this step, the devices
are identified according to their connections and parameters.
It is important to properly identify devices taking their
parameters into account as well as their connections.
* Second part of issue fixed (inverter chain ambiguity)
* Added test
* Updated tests
* Updated golden test results
* Updated golden test data for Windows
Co-authored-by: klayoutmatthias <matthias@klayout.org>
* First step for solution:
Problem was: the ambiguity resolver was making decisions which later resulted in
a name conflict. Later on, another branch of the backtracking algorithm came
across the same situation but decided based on names, creating an conflict.
First part of the solution is to establish the backtracking information
during ambiguity resolution and using that rather than an alternative branch
later on. This avoids this conflict, but does not favor names as mandated
by the "use_names" flag. This will be the second step of the solution.
* Bugfixed solution (partially)
* Introducing third pass in netlist compare
The second pass is "ambiguity resolution by name" and
is skipped if "consider_net_names" is false. The third
pass then is ignoring the names.
* Bugfix
* Comment fixed, test updates
* Added tests
* Added test data variant for CentOS 8
1. Be more careful with net names
Net names are used now for sorting the graph nodes, but not for
strict compare. This is useful to derive swappable pins for
blackbox circuits.
2. Be more careful with pins from schematic netlist
Pins from schematic netlist without a corresponding pin on the layer
side are treated as mandatory unless connected to a trivial net.
Pins connecting to non-trivial nets inside the subcircuit are always
considered mandatory.
This way schematic pins enforce corresponding layout pins.
On the other hand, layout pins connecting to trivial nets inside
the subcircuit are considered non-mandatory.
Previously: matching of blackbox pins was enforced
by using pin names for passive nets in the compare.
Problem: no match was achieved when pins are not
named or not named consistently.
In this case, it's desirable to treat them as
ambiguous.
The new solution is to let the ambiguity resolver handle
that using an extended definition of the net names:
it will take the pin name into account if an unnamed net
is attached to a pin.
In addition, net ambiguities are projected to pin
equivalence now. This also will propagate symmetry
through nested blocks (dbNetlistCompareTests:20_BusLikeConnections).
Abstract pins are created when pins are not attached to any or only to passive nets
(passive nets are those without device terminals or subcircuit pins).
1. Such pins were treated swappable. Now named pins will not be treated
swappable but are mapped by name. This enables blackbox models where
the pins are labelled and must correspond to schematic pins.
2. A bug was present which lead to incorrect handling of abstract
nets in net compare.
* WIP: some refactoring
* WIP: some refactoring
* Netlist compare: introducing ambiguity resolution by net names
By default now net names are used for resolving ambiguities.
If net names match, they will be used to associate nets if the
choice is ambiguous. This is usually much faster and more reliable
than trying to resolve ambiguities through topology analysis.
This feature can be disabled using "consider_net_names(false)" in
the LVS script.
* Some refactoring, Jenkinsfile modified for better test coverage
This enhancement targets towards a better resolution
of ambiguities. The enhancement is to utilize knowledge
about device and subcircuit equivalences to avoid stale
branches of the ambiguity resolution tree.
So far following these branches could lead to a
contradictions which render an ambiguitiy resolution
choice useless.
One effect of this change is enhanced reproducibility
of the matching log because some pointers are not
involved anymore.
One unit test was failing because the netlist compare did not
properly consider dropped pins:
* A severe bug ("g1" should be "g2")
* Incomplete detection of dropped pins upwards in the hierarchy
The general pin and net mapping scheme has been enhanced so that
net mapping to "0" is valid (this will happen in case of dropped
pins) and this condition is used to detect pins without match
requirement.
The problem was that with the floating test case, the
ambiguity resolution sometimes assigned the wrong pins
and floating pins/connected pins were swapped.
One option is to make the ambiguity resolver consider
the pin connection state when tenatively evaluating
nodes.
Another option is to put more emphasis on net names
and use them for ambiguity resolution. This has helped
here.
General topic: abstracts and swappable pins.
Issue: we work bottom up and assign pins. This is the
basis for net graph building. But swappable means those
pins can change. The compare works fine, but debugging
output is strange: as the pin assigned is fixed, the nets
found to be attached to a circuit might not fit any
proposed pin pair (which does not contain swapping).
The problem gets worse with abstracts.
The enhancements are
- Such cases generate only warnings in the browser
and the message says swapping might be the case
- Floating nets are treated differently. This should
lead to a better performance for abstracts/black boxes,
but in case of disconnected pins (due to wire errors),
floating nets happen to create mismatches in the nets above.
- Net graph building does not consider swappable nets. In
case of two swappable pins this wouldn't be an issue, but
for more than two this would create ambiguities and
prevent topological matching.
Plus: Debug output option for net graph
Tests updated
Matthias Koefferlein
Matthias Koefferlein