GF180 / Magic 8.3.678: hierarchy-sensitive DV.9 recognition with polygon-equivalent source input

[JerryZhong0910]

Observation

With the pinned generated GF180D SRAM source, Magic’s native bad_nwell mask depends on whether hierarchy is flattened before import. The hierarchical input produces 33 components; flattening already-imported Magic types preserves them. Flattening the complete GDS before import produces no bad_nwell, while the nonempty 126-component MV-well mask remains. Complete input polygon unions and 15,331 transformed text occurrences agree.

We used Magic 8.3.678, GF180D release f6eeac7dad085ffcc829ccfd721f7b4ce39edcf7, and the recorded readonly/noduplicates/maskhints settings. Supported CIF paint exported derived masks into separate diagnostic cells with background DRC catch-up disabled. These are mask queries, not full-deck DRC results.

Two source witnesses distinguish recognition: PMOS geometry at (146.370,324.915)–(151.865,328.855) µm changes from pmos to mvpmos; N-active/contact geometry within (335.370,26.035)–(335.790,27.865) µm changes from ndiff/ndiffc to MV well-tap types. Ancestor voltage/well markers cover these regions; the contributing leaves lack the same local context. Names and supply labels are not voltage evidence. Magic’s diffusion/device-seed scope also differs from KLayout’s PMOS-only predicate.

Question

Are ancestor DUALGATE/FET5VDEF/nwell markers intended to participate in typing these child shapes? If so, which reader/technology boundary should ensure this? Otherwise, what supported input preparation is intended for this source hierarchy?

Pre-import flattening is a diagnostic contrast, not a proposed production fix. We seek intended semantics, not a waiver, electrical acceptance, or a predetermined bug verdict.

Controls

Complete-source control	Recorded observation
Hierarchical R0; flatten after import	33 bad / 126 MV-well components; masks unchanged
Flatten before import	0 bad / 126 MV-well components
Hierarchical MX, origin (98.200,539.360) µm	Inverse-transformed masks/types equal R0
Original KLayout 0.30.9 DV.9 predicate	12,062 high-voltage PMOS regions; 0 low-voltage; 0 findings

Reproducer and environment

Source: gf180mcu_fd_ip_sram__sram512x8m8wm1.gds, SHA256 40d76d3ccfc8779c9db9f1db7a0bbccbbaf12c4627a3fa5b59049f23eef7d915.

Attached package: gf180_magic_dv9_repro.tar.gz.
Extract and use the actual repro/run.sh entry with --pdk-dir, --source-gds, --magic-bin, --magic-tcl-dir, --klayout-bin, and --output-root; PYTHON_BIN selects Python. repro/README.md documents every parameter and the verified historical source-acquisition route. No PDK/tool binaries or private wrapper are bundled. Magic source reference 73620475d7d70f72b475e746d5cf023b98f34eac is a release mapping, not immutable build attestation.

The source-only replay passed 31 comparisons after relocation on our existing installation. The launcher currently requires matching recorded tool binaries and PDK inputs; independent-machine reproduction has not been validated.

[JerryZhong0910]

GF180 / Magic #558 follow-up

Selective flatglob follow-up: watched M1 border tiles remain present

Following d.m.bailey's suggestion, I tested an import-time selective gds flatglob control on the original complete hierarchical GF180D SRAM source using Magic 8.3.678.

A source-derived set of 58 exact descendant-name additions changed the complete-source bad_nwell mask from 33 components to 0, while retaining the complete 126-component MV/well union and the expected PMOS/tap retyping.

This is a derived-mask / recognition result, not a full-DV.9 DRC closure. I therefore paused broader testing rather than treating the result as a production fix.

A subsequent saved MAG/contact-residue projection showed 704 small M1-border differences, totaling 3.0624 µm². That result is reproducible at the serialized-proxy level, but it is not a direct dump of the resident M1 plane.

I have now inspected two representative witnesses using:

*watch metal1 types

in a real X11 Magic layout window. The graphical frontend differs from the earlier -dnull runs, but the same retained Magic 8.3.678 tclmagic.so core was verified in the process maps. The complete source, all 58 flatglob additions, inherited startup pattern, and reader settings were unchanged.

*watch was explicitly rebound after every root/edit-cell switch, and the relevant child transform was checked with live root versus -edit coordinates.

Observation	Immediately after gds read	After flatten DV9_TYPED_FLAT, before first save
Complete-ring witness near (281.335, 396.940) µm	Four narrow border tiles labeled mvpsc on metal1	Corresponding border tiles remain labeled mvpsc
Partial-ring witness	Known top/right/bottom border segments labeled mvpsc	Those segments remain labeled mvpsc

The partial witness's separately watched child plane also shows overlapping m1.

The technology aliases mvpsc to mvpsubdiffcont and declares an M1 residue for that type. Ordinary display coloring and some surrounding composed types change; the observations above rely on the rebound *watch tile/type annotations, not on ordinary coloring or whole-context visual equality.

Native-plane screenshots — complete witness, left border

P — immediately after gds read, before flattening

Q — after flatten DV9_TYPED_FLAT, before the first save

In both views the narrow central strip is labeled mvpsc, with m1 on either side. The ordinary display coloring changes, so the comparison is based on the black *watch tile/type annotations.

These screenshots are representative visual witnesses only. They do not establish exact numerical tile equality, preservation across all 704 proxy-gap regions, cross-plane consistency, or electrical connectivity.

The subsequent MAG reproduces the earlier ordered paint records exactly. Strict whole-file equality excluding timestamps does not hold because label order differs, although the label/attached-port multisets match. The earlier 704-region proxy census was not rerun in this graphical observation task.

The current interpretation is therefore narrower than before:

The saved MAG/contact-residue proxy difference does not, by itself, demonstrate native M1-plane absence at the two watched witnesses.

I am not claiming that the 704 proxy differences are false, that flattening has been fully preservation-qualified, or that an electrical open has been ruled out across the full source. The relationship between the watched resident-plane tiles and the saved MAG home-plane/residue representation remains unresolved.

Question

Is this the intended interpretation of the watched resident plane?

Is there an existing read-only, non-composing export or traversal of those same resident plane tiles, before MAG home-plane filtering or residue decomposition, that retains:

• exact tile bounds and units;
• space tiles;
• raw and generated stacked-contact types;
• split-tile orientation and both side types;
• cell / edit-cell / transform provenance?

If no public Tcl command exposes this, which native observation point would you recommend for comparing the actual resident M1-plane state before and after the unchanged flatten operation?

No reader option, source geometry, production import policy, physical design, or production setting was changed. No full source/current DRC, tool instrumentation, rebuild, waiver, or production flattening adoption is claimed here.

[JerryZhong0910]

Readonly source-root output: all source payloads preserved

Following Sylvain’s suggestion, I checked the previously unmeasured source-root GDS output path for the selective gds flatglob recipe. gds readonly true was already enabled. The complete GF180D SRAM source, Magic 8.3.678, the 58 exact descendant-name additions, inherited *_CDNS_* pattern, and reader settings were retained.

One fresh import and one write of the original resident SRAM root completed, with no retry. This test did not execute the subsequent flatten DV9_TYPED_FLAT measurement operation or reload a saved MAG. After import, I explicitly selected the installed normal gdsii writer profile and self-contained output.

Comparison	Measured result
Source payload immediately after STRNAME, through and including ENDSTR	593/593 exact, totaling 248,833 records / 2,906,654 bytes
Selected and unselected definitions	All 58 selected and all 535 unselected payloads exact
References	All 4,733 SREF + 15 AREF records retained, including original duplicates, names, transforms, array dimensions and coordinates
Units and source geometry	Identical UNITS; all 16 nonempty polygon layer/datatype unions match; ignored layers []
Text	All source TEXT records retained; all 21 nonempty layer/datatype pairs, including the five text-only pairs, inventoried

All 593 definitions had valid source-associated GDS_FILE, GDS_START and GDS_END properties. The log recorded 593 copy messages, and no fallback or reference-only omission was observed. These properties, messages and exact payload comparisons support the readonly-copy interpretation; no function instrumentation was used.

The whole files and complete structures are not byte-identical. Every BGNSTR timestamp record changed; the library HEADER changed from 600 to 3, BGNLIB timestamps and LIBNAME changed, and structures were reordered. Structure/reference names and within-structure payload order were preserved. No unexplained record differences remained. These are accounted output differences, not a claim of universal downstream-reader compatibility; readback was checked with KLayout 0.30.9.

This establishes source-only output-content preservation for this tested recipe/root/writer path. It does not establish preservation when exporting the diagnostic flattened cell, or numerically validate Magic’s resident M1 planes. The earlier recognition and visual-watch results are carried evidence, not measurements repeated in this run. No full DRC, electrical qualification or production adoption follows from this test.

The separate question remains: is there an existing read-only, non-composing export of the actual resident M1-plane tiles displayed by *watch metal1 types, before MAG home-plane filtering or residue decomposition, retaining exact bounds/units and split or generated stacked-contact types?

The original source GDS, current implementation and production settings remain unchanged.