Device recognition

Connectivity extraction recovers nets; device recognition goes one level up and recovers the transistors those nets connect. It is a new module in reticle-extract (device), a sibling of the connectivity types, not a change to them.

A gate is poly over diffusion

A MOSFET is where a poly shape crosses a diffusion shape: that overlap is the channel (the gate). The extractor:

1. Flattens the cell and finds every poly-over-diffusion overlap that fully crosses the diffusion (a partial overlap leaves diffusion on only one side and is not a channel).
2. Classifies each gate as NMOS or PMOS from the surrounding implant and well: p+ select (psdm) or an nwell means PMOS; n+ select (nsdm) or bare substrate means NMOS. Each of those questions is asked of the diffusion and channel polygons, not of the boxes round them: an implant lying in an L-shaped diffusion’s notch touches the box and not the diffusion, and would flip the device’s polarity.
3. Measures the channel: gate length is the channel’s extent across the poly, and gate width is the channel’s area divided by that length, which is the width of the rectangle with the same area and the same length. On a rectangular channel that is exactly the diffusion extent under the poly. On any other channel the extent is measured across the box round the channel and counts silicon the gate does not cover, so reading the width off it overstates the transistor’s drive: measured at 36% on the fixture in crates/reticle-extract/tests/device_nonrect.rs.

Why a transistor needs more than connectivity

Pure connectivity sees a single diffusion rectangle as one net: a plain wire and a transistor look identical to a same-layer union-find, so source and drain come out shorted. That is wrong for a transistor, whose channel does not conduct at DC.

Device recognition fixes this by splitting the diffusion by its gate before it assigns terminal nets. Each diffusion is cut into the lobes on either side of every channel, and connectivity is extracted over that cut geometry (reusing the same Extractor, with the SKY130 contact/via stack plus a body-tie path). The result is that a transistor’s source and drain land on distinct nets exactly when the layout wires them apart, and the gate, source, drain, and bulk terminals each bind to a real net.

Device-level LVS-lite

compare_devices compares an extracted device netlist against an expected one by device kind and terminal-net connectivity: each device reduces to its kind, gate, unordered source/drain, and bulk net names, and devices are matched by that signature. It reports the devices each side has that the other does not, catching device-count and terminal-net mismatches. The match is name-based, so both sides name their nets (the layout through label geometry, the schematic directly). This extends the connectivity compare_netlists additively; that function is unchanged.

Scope and limits

This is deliberately “lite” and honest about its edges:

• Recognizes NMOS and PMOS only: no parasitic devices (diodes, capacitors, bipolars), no JFETs, no ESD structures.
• No device-parameter matching beyond reporting W/L: compare_devices matches on connectivity, not on W/L tolerance or model name.
• No series/parallel device folding and no hierarchical device extraction; it works over the flattened cell.
• Bulk binding is best-effort from the nearest matching body tap; an untapped body is left unbound rather than guessed.
• Source and drain are geometrically symmetric, so their labelling is a stable low/high convention, not a claim about circuit function.

Oracle

The recognition is checked against an independent tool, but not yet on the same input on both sides, and this section says so rather than implying otherwise. scripts/device-oracle.ps1 runs Magic’s own device extraction on the real production GDS (crates/reticle-app/assets/sky130_fd_sc_hd__inv_1.gds) inside the pinned hpretl/iic-osic-tools container (Magic + the sky130A PDK, the same image the tt-precheck recipe uses): Magic extracts 1 NMOS + 1 PMOS with gate A, drains Y, and sources on VGND / VPWR. The extractor side of the comparison runs over a hand-built, axis-aligned golden fixture that mimics the same topology and net names (crates/reticle-extract/tests/fixtures/inverter.md), not the production GDS itself, and reports the same device count, kinds, and terminal connectivity. The two runs are on different inputs: the agreement shown is that the extractor’s device model matches Magic’s on an equivalent circuit, not yet that it matches Magic on the identical production layout. Running the extractor directly over the imported production GDS and diffing against the same oracle run on that file is an open gap (docs/honest-limits.md). When Docker or the image is unavailable the tests fall back to the golden fixture and state the limitation.

A full multimodal oracle and an oracle-agreement table across more cells are a separate lane; this chapter documents only the device recognition and its Magic device-count agreement on equivalent, not identical, inputs.

What this oracle structurally cannot see. The golden fixture, every other fixture in crates/reticle-extract/tests/, and both shipped gallery designs are built from axis-aligned rectangles, and on a rectangle a shape’s bounding box IS the shape. So no amount of agreement on that corpus can distinguish an extractor that measures the channel polygon from one that measures the box round it, and a real defect of exactly that kind survived every green fixture and both gallery designs, which read byte-identical before and after the fix. The fixtures that CAN see it are crates/reticle-extract/tests/device_nonrect.rs, each one the smallest layout where the polygon answer and the hull answer differ:

cargo nextest run -p reticle-extract --test device_nonrect

A gallery-only or rectangle-only check is not a check of this property. That is a statement about the corpus, not about the extractor.