In order to accurately find the rectangles (Components) causing a short
circuit, we need to aggregate the equipotentials as soon as we starts
to merge the tiles. Because tiles being a union set, the tree compression
forbid to know which tile overlap which one afterwards. So the equipotentials
are created early on the fly. We also add an accounting of all the net's
components (Plug excluded) to know if it is fully included in the
equipotential. If not, we have an open.
This is an impacting change from the previous version in which we build
the equipotentials *after* aggregating the tiles only. The added cost
comes from the number of equipotential merging that we have to perform
when we merge tiles. Almost two times slower. May need to have a deep
look on how to optimize it later (efficient merge or keeping the order
tiles where merged).
* New: Equipotential elements includes now:
1. Components at the top level (the cell owning the Equi).
2. Nets at the top level. If an equi include all the components
of a Net, own the Net, not all it's individual components.
3. Other equipotentials from the Instances immediatey below.
Thoses equis should be equivalents to the Plug of the Net.
They are stored in the form of Occurrences <Instance,Equi>,
the relation is stored on that Occurrence.
* New: Equipotential::getFlatComponents(), a collection to recursively
get all the *component* occurrences of the equi. Transhierarchically.
Go through components, nets components, and recursively through
the child equis.
* New: EquipotentialRelation, the master of this relation is the
Equipotential and the slaves, all its elements.
* Change: In Tile, in case the tile is build on a deep component,
we trace up the Equipotential it belongs to in the Instance
level immediately belonging to the Cell under extraction.
They must exists as we extract from bottom to top all the
master cells. So we have, for that tile an Occurrence
<Instance,Equi> that we can store in the current Equi level.
* Change/Bug: In Tile, add an Id to be reliably sort the tiles
in the IntervalTree. As we replaced the tile component occurrence
by a <Instance,Equi> we were having multiple tiles with the same
equi. This was causing havoc again in the IntervalTree.
Should add a check in the RbTree for elements with the
exact same key, but that would imply passing a new template
parameter for the "equal" function.
Jean-Paul Chaput