Parallel series mosfet matching depends on order of devices

[d-m-bailey]

Netgen 1.5.155

The matching of parallel series of mosfet appears to depend on the order of mosfets in the netlist.

The tarball contains 2 sample netlists. One extracted from the layout, with devices as mosfets, and the other a modified version of the cdl library. The cdl contains 2 cells that are equivalent: the only difference being the order of the MMPA1 and MMPA1x devices. The device connections are exactly the same. Only the order that they appear in the netlist is different.

I've attached a test case. Extract the tar file and then

run netgen -noc < lvsin2 to show that one subckt matches, but the other does not.

May be fixed by the recent symmetry changes. o21a.tar.gz

[RTimothyEdwards]

Yes, this is exactly the "symmetry" thing. I have come to understand the symmetry breaking problem much better now. In essence, the problem is that cells in digital layouts with no inputs or outputs (decap cells, tie-down cells, fill cells, etc.) are all unresolvable internal symmetries. Breaking the symmetries one fill cell at a time and then re-running convergence takes a huge amount of time. Breaking the symmetries all at once works great---but only because these cells are all completely identical. For symmetries with connectivity between them, you have to go the route of breaking each symmetry one by one and rerunning convergence. For the time being, I have added an option switch "-full" to the "lvs" command. So you can just add "-full" at the end of each command in the "lvsin2" script and it all works properly. I do intend to figure out exactly what condition or conditions allow symmetries to be broken all at once, because I would prefer to automate the choice of "full" or "fast" symmetry breaking, rather than the ad-hoc method of saying "run it this way, and if it gives you a bad result, then run it the other way". Other approaches may work, too, like saving the state of the system before symmetry breaking, and if it runs into the "Networks match locally but not globally" error, then restore that state and run again with full symmetry breaking. But I would prefer to be able to look through all devices and nets in the compared lists and be able to say "all of these can be grouped together and run once" and that should always be right.

Thanks for providing the most minimal circuit that shows the "match locally but not globally" problem. That will be a huge help to me in getting the proper solution for it.