LVS passes for cells at the block level but shows errors for the same cells at the top level

[d-m-bailey]

@RTimothyEdwards This was seen in a chipIgnite project and also the wafer.space tinytapeout chip. The test case is from the pure digital gf180mcu tinytapeout

Netgen 1.5.311

Using the same extracted netlist and source files, there are 4 blocks that pass LVS when run individually, but fail when checked as part of the full chip. (See noflatten.glob in the tarball)

netgen_test.tgz

tar xzf netgen_test.tgz
cd netgen_test
source run_all

Contains

# data
spice/  <- spice source files
verilog/  <- verilog source files
layout/ <- extracted layout spice file

# commands
run_lvs  <- run LVS for one block using default setup
run_ok_lvs  <- run LVS for one block using setup that pre-flattens or ignores conflicting subckts
run_all  <- list of all commands to demonstrate issue

# outputs
artifacts/  <- my results from executing the commands in run_all

# netgen commands 
lvs.script  <- use default setup
lvs.ok.script  <- use setup that pre-flattens or ignores conflicting subckts

# cells to avoid flattening if mismatched
noflatten.glob  <- these cells pass LVS when run separately, but fail when included in the top level 

# setup files
gf180mcuD_setup.tcl  <- default
gf180mcuD_setup.ok.tcl  <- flatten or ignore conflicting subckts.

# list of subckt definitions that have conflicting port lists
mismatch.port.list

It appears that the problem occurs intermittently when multiple layout cells with different port orders are equated to the same source subckt. The N-1 equating is required because magic prefixes cells from different gds files with a unique 2 byte code and an underbar.
We found that preflattening the conflicting cells results in a match.

It may be easier to change magic to extract the ports in a deterministic order (alphabetic?). What do you think?

@H-Ojiro