Hierarchical connectivity not extracting through levels with no connections to unlabeled nets

[d-m-bailey]

Seen on slot-012 of chipignite 2206q_b.

• Lower levels do not have text or pins.
• nwell is extracted as connected to #m4_x_y (autogenerated name) at level 3 (not a port).
• Level 2 has no text or pins connecting to any layers on that net.
• Level 1 has a VDD metal2 pin over the metal2 that is 2 levels down, but this connectivity is not extracted.

I can create a private test case.

[d-m-bailey]

@RTimothyEdwards Similar to this but on an open source project. Sky130 MPW-6 slot 031.

Standard hierarchy, but generated with Cadence Innovus.

user_project_wrapper
+-user_proj_example
  +-sram

Power to sram is not connected at the user_proj_example level. At the user_project_wrapper level, there are via4 over the sram macro that drop from met5 passing through nothing on the user_proj_example level to connect to the met4 power rails in the sram macro. magic is not extracting this connection.

However, if I add met4 over the sram macro at the user_proj_example level, magic does extract the connection from user_project_wrapper to sram.

No connection detected:

user_project_wrapper    --- met5 ---
                            via4
user_proj_example
sram                    --- met4 ---

Connection detected:

user_project_wrapper    --- met5 ---
                            via4
user_proj_example       --- met4 ---
sram                    --- met4 ---

Unfortunately, this is not an optimal example because the power rail connections to the standard cells are missing.

I have layout data with the user_proj_example standard cell power connected, if that's needed.

[d-m-bailey]

Ignore this comment. The connections are extracting correctly.

@RTimothyEdwards additionally, slot-028 of mpw-7 has cross hierarchy connections to non-port layers that appear to miss connectivity.

RRAM_ANALOG_MPW7 Level 3 only data: ports on met3 and met4

Level 3 and 4 data: met2 connection to port.

Level 2 and 3 data: met2 not connected to met3/4

Level 2 through 4 data: met2 connection bypassing met3/4 on level 3

Flattening the hierarchy will yield a correct extraction, so there is a work around.

However, there is the possibility of a false clean LVS result if cross hierarchy shorts exist but are not extracted.

I think this is a critical issue. I think magic either needs to extract cross hierarchy connections to non-ports or flag them as errors.

Flagging as errors might be easiest. During extraction, maybe copy the lower level non port conducting layers to obstruction layers in the parent hierarchy. Any contact in the parent between conducting layers and obstruction layers would flag an error. Using flatglob in subsequent runs until there are no errors would eventually give the correct result.

Another option is to recognize cross hierarchy connections and virtually flatten the layout at that point, but this results in an extracted hierarchy that does not match the layout.

[RTimothyEdwards]

I'm not really getting what the problem is. Is there a reproducible result with a simplified case?

[d-m-bailey]

@RTimothyEdwards All the sample layouts I try to make work without any problems, so my initial assumption of the cause seems to be incorrect.

I'll attempt to reduce the problematic layout to a simple case that still extracts incorrectly.

[d-m-bailey]

@RTimothyEdwards Sorry for the false flag. CVC was detecting a floating gate error which I assumed was due to a unextracted connection. It turns out it was due to an undefined input.

I'm still getting a LVS mismatch between hierarchical extraction and flattened extraction though - I'll work on a minimal case. circuit 1 is the hierarchically extracted net that netgen flattens while circuit 2 was flattened before extraction with FLATGLOB. nets are the same, but device counts don't match. I imagine that's due to cross hierarchy parallelism not being reduced. Like I said, I'll work on a test case.

Contents of circuit 1:  Circuit: 'PK_user_project_wrapper'
Circuit PK_user_project_wrapper contains 317156 device instances.
  Class: sky130_fd_pr__nfet_01v8 instances: 155453
  Class: sky130_fd_pr__pfet_01v8_hvt instances: 154860
  Class: sky130_fd_pr__pfet_01v8 instances: 496
  Class: sky130_fd_pr__nfet_g5v0d10v5 instances: 3328
  Class: sky130_fd_pr__diode_pw2nd_05v5 instances: 1205
  Class: sky130_fd_pr__res_generic_po instances:  22
  Class: sky130_fd_pr__reram_reram_cell instances: 256
  Class: sky130_fd_pr__pfet_g5v0d10v5 instances: 1536
Circuit contains 64677 nets, and 553 disconnected pins.
Contents of circuit 2:  Circuit: 'PK_user_project_wrapper'
Circuit PK_user_project_wrapper contains 123447 device instances.
  Class: sky130_fd_pr__nfet_01v8 instances: 59365
  Class: sky130_fd_pr__pfet_01v8_hvt instances: 58775
  Class: sky130_fd_pr__pfet_01v8 instances: 496
  Class: sky130_fd_pr__nfet_g5v0d10v5 instances: 1792
  Class: sky130_fd_pr__diode_pw2nd_05v5 instances: 1205
  Class: sky130_fd_pr__res_generic_po instances:  22
  Class: sky130_fd_pr__reram_reram_cell instances: 256
  Class: sky130_fd_pr__pfet_g5v0d10v5 instances: 1536
Circuit contains 64677 nets, and 553 disconnected pins.