"floating" text connected rather than underlying metal

[d-m-bailey]

gf180mcuD process magic 8.3.602

The expected connectivity is traced

With one level of hierarchy shown, you can see the driver cell with a Y text placed over it, but no metal. The Y text is a port on the driver cell's parent xor2.

With all levels shown, the metal1 connection is apparent (Y of xor2 is DOUT of driver).

However, the extracted netlist shows a disconnect.
driver is as expected.

.subckt driver DIN VSS DOUT VDD
X0 a_245_256# DIN VSS VSS nfet_03v3 ad=0.1936p pd=1.76u as=0.1936p ps=1.76u w=0.44u l=0.28u
X1 VDD a_245_256# DOUT VDD pfet_03v3 ad=0.1872p pd=1.24u as=0.1872p ps=1.24u w=0.72u l=0.28u M=4
X2 a_245_256# DIN VDD VDD pfet_03v3 ad=0.3168p pd=2.32u as=0.3168p ps=2.32u w=0.72u l=0.28u
X3 DOUT a_245_256# VSS VSS nfet_03v3 ad=0.2288p pd=1.4u as=0.3872p ps=2.64u w=0.88u l=0.28u M=2
.ends

xor2 however, has a floating Y port (it should be connected to driver_0/DOUT.

.subckt xor2 Y VSS VDD B A
Xdriver_0 driver_0/DIN VSS driver_0/DOUT VDD driver
Xinv_s_0 VDD VSS inv_s_0/Y B inv_s
Xinv_s_1 VDD VSS inv_s_1/Y A inv_s
X0 VDD A a_1605_618# VDD pfet_03v3 ad=0.1584p pd=1.6u as=93.59999f ps=0.88u w=0.36u l=0.28u
X1 VSS inv_s_0/Y a_1605_100# VSS nfet_03v3 ad=0.1584p pd=1.6u as=93.59999f ps=0.88u w=0.36u l=0.28u
X2 driver_0/DIN B a_1042_618# VDD pfet_03v3 ad=0.1584p pd=1.6u as=93.59999f ps=0.88u w=0.36u l=0.28u
X3 driver_0/DIN A a_1042_100# VSS nfet_03v3 ad=0.1584p pd=1.6u as=93.59999f ps=0.88u w=0.36u l=0.28u
X4 a_1605_618# inv_s_0/Y driver_0/DIN VDD pfet_03v3 ad=93.59999f pd=0.88u as=0.1584p ps=1.6u w=0.36u l=0.28u
X5 a_1605_100# inv_s_1/Y driver_0/DIN VSS nfet_03v3 ad=93.59999f pd=0.88u as=0.1584p ps=1.6u w=0.36u l=0.28u
X6 a_1042_618# inv_s_1/Y VDD VDD pfet_03v3 ad=93.59999f pd=0.88u as=0.1584p ps=1.6u w=0.36u l=0.28u
X7 a_1042_100# B VSS VSS nfet_03v3 ad=93.59999f pd=0.88u as=0.1584p ps=1.6u w=0.36u l=0.28u
.ends

The parent puf_readout_v2 has a VALID_OUT connection to the "floating" xor2 terminal Y, but no connection to the underlying driver terminal DOUT.

.subckt puf_readout_v2 VSS VDD DIN1 DOUTB RST_N DIN0 SELB<5> SELB<0> DOUT SEL<7> SELB<1>
+ SELB<4> SEL<6> SEL<4> SEL<1> SEL<3> SEL<2> VALID_OUT SELB<2> SELB<6> SEL<5> SELB<3>
+ SELB<7> SEL<0> 
Xxor2_0 VALID_OUT VSS VDD DOUTB DOUT xor2

1. Adding a small metal1 square under the floating Y text on the xor2 results in a correct extraction.

2. Removing the Y text also results in a correct extraction. (The driver/DOUT net is promoted to an xor2 port and connected to VALID_OUT).

magic-test.tgz

# set PDK_ROOT
export PDK=gf180mcuD
tar xzf magic-test.tgz
cd magic-test
magic -dnull -noc -rcfile $PDK_ROOT/$PDK/libs.tech/magic/$PDK.magicrc < extract.tcl

The resulting spice file is puf_readout_v2.layout.spice. I've included puf_readout_v2.602.layout.spice as a reference for the file generated in my environment.

[d-m-bailey]

@RTimothyEdwards Do you get notified about these issues even if you aren't tagged?

[RTimothyEdwards]

@d-m-bailey : Yes, I do. However, there is no option for "please wait until I'm not overwhelmed with stuff to notify me".

[RTimothyEdwards]

@d-m-bailey : Man, I hate corner cases.

So magic was doing the right thing, and finding the label, and determining that it had to find how the label connects.
But the label was a point label and had zero area, and there was no other geometry close to the label, so the "interaction area" was reduced to the size of the label. With a zero-sized area, various area checks failed because there can be nothing inside the area. The simple solution was to expand the interaction area so that it is no longer zero sized.

This may impact some issues I was having with the GF180MCU SRAM, as well. I was forced to draw metal under several labels to get the right LVS result and I couldn't figure out why, and why it seemed to be so arbitrary. Now I understand what was happening.

The fix is in magic version 8.3.620.