Hello, I'm not sure if this is a bug in netgen or if I am just misunderstanding something fundamental, but I have some cells with no active devices. These cells contain nodes that are floating within the cell, but connected to power or ground at a different level of hierarchy. In the layout I can trace the net to the power rail, and I see the net shape physically connected to power/ground. The extraction seems reasonable, but netgen creates a new net for the "floating" net in the reference netlist that remains unconnected. wlstrap/not_floating is an example of this. This worked in a previous version of magic/netgen. Do I need to just add pins on these and then explicitly connect them in the reference netlist despite the subcircuit for these cells being empty? The lvs report, run script, and layout is attached.

I've had some success with flattening cells that have mismatching pins before extraction using

flatglob

. Commercial tools may do this automatically, but magic isn't there yet. Doesn't work if you have

gds readonly

set.

gds flatglob cell1_*
gds flatglob cell2_*

# list cells to be flattened
puts "Flattening [gds flatglob]"
gds flatten yes
gds read <gds_file>

load <top> -dereference
extract do local
extract unique
extract

Most likely using

flatglob *wlstrap*

before doing extraction in Magic would help things. Or using Mitch's special netgen version that refuses to create proxy pins, which I wanted to merge into the netgen code base as an option (hint, hint, Mitch).

where can I find this special netgen version? I've tried flatglobing the wlstraps already.

https://github.com/d-m-bailey/netgen/tree/pin_match But it's 15 commits behind the current master.

Thanks

with latest netgen i also having LVS issue: https://github.com/The-OpenROAD-Project/OpenLane/issues/1313

Using Mitch's netgen fork I still see proxy pins

What does

netgen -batch

return as a version number?

1.5.215 which I think corresponds to your version

Should be 1.5.215-P1 or something like that. Are you compiling the

pin_match

branch?

ah my bad I was on master of your fork

@Mitch Bailey: Can you make a pull request from that? I'll probably merge it by hand, but that will give me all the file differences, which will be helpful.

Yes, I'll do that in the morning.