Multiple ports connected with verilog assign do not match.

[d-m-bailey]

Netgen 1.5.265

In verilog, top level assign statements can be used to effectively short port nets. magic can extract multiple ports on the same physical net by placing a virtual resistor between the connected ports.

Unfortunately, this sometimes does not pass netgen LVS.

The sample case shorts all io_oeb signals to wb_rst_i.
lvs.script runs on the normal netlists and does not pass.
lvs.ok.script runs on netlists with the above shorts commented out and give a clean result.
lvs.one.script runs on netlists with only one io_oeb net shorted to wb_rst_i and does not pass.

export PDK_ROOT and PDK.

1. tar xzf test-short.gz
2. cd test-short
3. netgen -batch source lvs.script
4. netgen -batch source lvs.ok.script
5. netgen -batch source lvs.one.script

test-short.tgz

A possible solution that we previously discussed would be to create a virtual net that multiple pins connect to. All device connections would have to be rewired to connect to this virtual net instead of separate shorted pins.

Another possible solution would be to always use the least net and short all other nets to it. Device connections to shorted pins would be rewired to connect to the least net. The least net could be determined alphabetically or by some other means common to both the layout and schematic.

[RTimothyEdwards]

I think this is solvable by another method. All shorted pins are by definition permutable. Netgen is always identifying the shorted pins, so I can call PermuteSetup() whenever any one is found. Then I just need to figure out where in MatchPins() to check for permutations.

[RTimothyEdwards]

After looking into it briefly, I think the issue is a red herring and the problem is deeper and more insidious. The MatchPins() routine should have correctly matched the pins. The problem is that only 7 or 8 pins were in the list of nodes passed to MatchPins(). I'm still investigating why.

[RTimothyEdwards]

@d-m-bailey : Netgen version 1.5.269 should fix this problem.
The root cause of the problem was fixing another problem (a while ago), also having to do with shorted pins. An original method I had used for shorted pins was to group them together, but then it was found that moving the pins around like that caused other matching issues. But at the time I wasn't sure if there was other code that depended on the shorted pins being grouped together. So you found one of those (I think the only one).

The only potential issue now is that the reason that I had grouped shorted pins together was to avoid an extra loop over pins; without the grouping, I now have a place in the code that does a triple loop over pins. This example has a "largish" number of pins, and I don't see any noticeable performance impact, so I'm going to assume it's not an issue. But keep an eye out.

[RTimothyEdwards]

If you have a chance, please check that #80 and #81 are (still) properly resolved. #81 was the issue whose solution caused this problem.