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

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

Summary

The ORFS GF180 platform technology LEF used by the default 5LM/9K/9t configuration does not define the Nwell MASTERSLICE layer, while the SRAM LEF present in the tested Ciel/open_pdks-generated GF180MCU PDK revision 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 tested macro LEF contains M1/M2/M3 interior routing obstructions.

Source scope

The SRAM LEF used in this reproduction comes from the tested Ciel/open_pdks GF180MCU revision:

PDK revision:
f6eeac7dad085ffcc829ccfd721f7b4ce39edcf7

gf180mcuD/libs.ref/gf180mcu_fd_ip_sram/lef/gf180mcu_fd_ip_sram__sram512x8m8wm1.lef

In that generated PDK collateral, the macro OBS begins with Nwell.

The installed metadata maps this release to standalone SRAM revision b98653230f05be17867c70870ecacfa6a6bca7ff. The LEF at that revision does not contain an Nwell obstruction; its OBS begins at Metal1.

For gf180mcu_fd_ip_sram__sram512x8m8wm1, the exact-release gf180mcuC and gf180mcuD generated LEFs are byte-identical, and their GDS files are also byte-identical. This equivalence is limited to this macro's LEF/GDS and does not imply equivalence between the complete C and D technology stacks.

The tested generated macro abstraction is produced through the SRAM-specific open_pdks/Magic path: the vendor collateral is imported and annotated, and Magic regenerates the macro LEF using lef write ... -hide 5um. Replay from the retained Magic hierarchy reproduces the installed macro body, including the Nwell-first OBS. This path is separate from open_pdks fix_techlef.py, which processes technology-LEF layer declarations.

So this report remains specifically about compatibility between the ORFS checked-in GF180 technology vocabulary and the SRAM collateral in the tested Ciel/open_pdks-generated PDK revision. It does not treat that generated SRAM LEF as a unique upstream authority. Full historical build reconstruction, including the first release in which this generated obstruction appeared, remains incomplete.

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 tested GF180MCU PDK technology collateral contains an Nwell MASTERSLICE declaration:

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

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

Macro side

The tested Ciel/open_pdks SRAM LEF gf180mcu_fd_ip_sram__sram512x8m8wm1.lef contains one OBS section whose first layer is Nwell, followed by M1/M2/M3 routing obstructions.

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.

These controlled routing runs used LibreLane Classic 3.1.0.dev2 with the recorded OpenROAD 26Q1-1024-gdcf36133a build and ORFS-derived 5LM/9K implementation inputs.

The downstream checks below are bounded verification results rather than a claim of end-to-end technology-stack or signoff qualification. In the documented descendant, KLayout used the installed gf180mcuD DRC environment with 5LM/11K selected and antenna/density excluded. LVS passed at the hierarchical SRAM macro boundary; SRAM-internal transistor-level LVS was not performed. OpenROAD route DRC is a separate check from these downstream GDS checks.

A: transient restoration of the intended 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 Nwell MASTERSLICE declaration matching the tested PDK vocabulary. 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

A fresh project-level rerun from the earliest affected stage reproduced the same result, and the resulting DEF was byte-identical to the earlier transient-OBS-restoration A/B result.

This isolates the missing Nwell vocabulary as the relevant compatibility factor for the observed OBS-import failure with the tested Ciel/open_pdks SRAM collateral.

Suggested upstream direction

The generation mechanism of the tested SRAM abstraction is now identified.
The remaining upstream question is which generated GF180 macro collateral ORFS
intends to support, and which technology-layer vocabulary its checked-in GF180
platform should expose for that support.

The following remain compatibility candidates for maintainer review rather than
a demonstrated canonical solution.

If ORFS intends to support this generated collateral, a minimal candidate for the observed failure is to add the corresponding Nwell MASTERSLICE declaration to the 5LM/9K tech-LEF source/template and 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 review 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;
• treating the tested generated SRAM LEF as the unique authoritative upstream source;
• 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 demonstrated issue is a compatibility mismatch between the ORFS GF180 stack-specific technology vocabulary and the SRAM LEF present in the tested Ciel/open_pdks-generated GF180MCU PDK revision. The tested macro-generation mechanism is identified; complete historical build reconstruction and broader end-to-end technology-stack qualification remain separate from the reproduced OBS-import failure.

Start with flow/platforms/gf180/config.mk and the selected flow/platforms/gf180/lef/gf180mcu_5LM_1TM_9K_9t_tech.lef, then compare its layer declarations with the tested SRAM LEF and reproduce the OpenDB import warning. Review the proposed technology-vocabulary change with maintainers; done means the supported macro OBS imports without ODB-0176 and its M1/M2/M3 obstructions remain present in the routing database.