GF180 platform tech LEF omits Nwell, causing SRAM OBS truncation on OpenDB import

[JerryZhong0910]

Summary

The ORFS GF180 platform technology LEF used by the default 5LM/9K/9t configuration does not define the Nwell MASTERSLICE layer, while the authoritative GF180 SRAM macro LEF uses Nwell as the first layer in its single OBS section before its Metal1/Metal2/Metal3 obstructions.

With this combination, OpenDB reports ODB-0176: undefined layer (Nwell) referenced. For this macro and OBS ordering, the later M1/M2/M3 obstruction geometry does not materialize in the routing database, while the macro pins still import normally.

This can allow detailed routing to traverse the SRAM macro interior even though the macro LEF explicitly intends M1/M2/M3 interior routing obstructions.

ORFS side

The GF180 platform selects its checked-in stack-specific technology LEF directly from flow/platforms/gf180/config.mk:

export TECH_LEF ?= $(PLATFORM_DIR)/lef/gf180mcu_$(METAL_OPTION)_$(KVALUE)K_$(TRACK_OPTION)_tech.lef

For the tested default stack this resolves to:

flow/platforms/gf180/lef/gf180mcu_5LM_1TM_9K_9t_tech.lef

That file defines Poly2, CON, Metal1..Metal5, Via1..Via4, etc., but no Nwell or Pwell layer vocabulary.

The pinned GF180 PDK library technology LEF used as the authoritative vocabulary source contains:

LAYER Nwell
  TYPE MASTERSLICE ;
  PROPERTY LEF58_TYPE "TYPE NWELL ;" ;
END Nwell

The complete PDK library tech LEF is for a different library/stack context and should not be loaded wholesale alongside the ORFS 5LM/9K tech LEF. The observed incompatibility is specifically the missing process-layer vocabulary required by the macro LEF.

Macro side

The authoritative SRAM LEF gf180mcu_fd_ip_sram__sram512x8m8wm1.lef contains one OBS section whose first layer is Nwell, followed by full-interior obstructions on M1/M2/M3.

In the failing routing database:

SRAM pins imported: yes
SRAM master obstructions: 0

The import warning is:

ODB-0176: undefined layer (Nwell) referenced

OpenDB's LEF geometry import returns on the undefined layer; because Nwell is first in this particular OBS, the following M1/M2/M3 shapes are not created. This is ordering-dependent rather than a claim that all undefined-layer cases are globally atomic.

Controlled A/B evidence

I tested the routing behavior without modifying the SRAM LEF/GDS.

A: transient restoration of the authoritative M1/M2/M3 OBS semantics

Restoring the exact macro OBS as native OpenDB master obstructions caused:

non-pin DUT-top routes inside restored OBS: 190 -> 0
OpenROAD route DRC: 0
KLayout DRC: 0
LVS: PASS
Antenna: PASS
STA: PASS

The historical macro-interior cross-hierarchy metal/via violations disappeared. Two known exterior M3 spacing cases also moved away due to incidental rerouting; they were outside the OBS and were treated as negative controls, not direct OBS repairs.

B: isolated stack-matched tech-LEF candidate

I then made an isolated copy of the active ORFS 5LM/9K tech LEF and added only the authoritative Nwell MASTERSLICE declaration. No SRAM, PDK, routing-rule, Pwell, or canonical ORFS collateral was modified.

Native import then produced the same M1/M2/M3 macro OBS fingerprint as the transient A/B restoration, with no ODB-0176 warning and no inaccessible macro pins.

The bounded regression matched the transient-restoration A/B exactly in the checked routing metrics:

non-pin routes inside native OBS: 0
OpenROAD route DRC: 0
KLayout DRC: 0
LVS: PASS
Connectivity: PASS
Antenna: PASS
STA: PASS
wirelength delta vs transient A/B: 0
via-count delta vs transient A/B: 0
congestion delta vs transient A/B: 0

This isolates the missing Nwell vocabulary as the relevant compatibility factor for the observed SRAM OBS-import failure.

Suggested upstream direction

Could the GF180 platform tech-LEF assembly be reviewed so the stack-specific tech vocabulary contains the process MASTERSLICE layers required by supported GF180 macro LEFs?

A minimal candidate for this observed failure is to add the authoritative Nwell declaration to the 5LM/9K tech LEF source/template, then regress native macro OBS import.

Pwell is also systematically absent in the checked GF180 tech-LEF family and may deserve a separate coherence review, but I would keep it separate from the minimal causal fix unless maintainers prefer to update the process-layer vocabulary as a set.

It may also be useful to add a regression/assertion that every layer token referenced by imported macro LEFs exists in the active technology LEF, so an OBS section cannot silently lose later routing obstructions after a warning.

Scope / non-proposals

This report is not proposing:

• modifying the SRAM hard-macro LEF or GDS;
• loading the complete PDK 11K tech LEF together with the ORFS 9K tech LEF;
• reconstructing full macro GDS geometry as routing blockages;
• treating OpenDB's fail-soft behavior as the primary root cause.

The primary compatibility boundary appears to be the ORFS GF180 stack-specific technology vocabulary; OpenDB's warning-only truncation is a secondary robustness concern.

[JerryZhong0910]

Follow-up with a fresh project-level qualification result.

I reran the flow from the earliest stage affected by the tech-LEF import using only the authoritative five-line Nwell MASTERSLICE addition in an isolated ORFS worktree. No SRAM LEF/GDS, PDK, RTL, SDC, placement, or canonical ORFS collateral was modified. Native import restored the SRAM Nwell/M1/M2/M3 OBS, non-pin routing inside the macro OBS went from 190 to 0, and the fresh descendant completed with OpenROAD route DRC = 0, KLayout DRC = 0, LVS/connectivity/antenna/STA all passing. The resulting DEF is byte-identical to the earlier transient-OBS-restoration A/B result, so the native Nwell fix reproduces the same routing solution independently.

I have therefore adopted this only as a project-local qualified overlay for now, not as an upstream/canonical ORFS change. One broader question raised in discussion is whether this should really be treated as a one-lineage Nwell omission, or whether the GF180 platform tech-LEF family in ORFS should be reviewed against the current open-PDK lineage more generally (including the historical 5LM/9K collateral), rather than maintaining copied technology data independently. I’d be interested in maintainer guidance on whether a minimal Nwell-only PR is useful, or whether you would prefer a broader source/assembly synchronization review first.