SKY130 grounding

Reticle uses real data from the open SkyWater SKY130 PDK so that its technology file, its 3D layer stack, its DRC subset, and its tier-5 benchmark tasks are grounded in cited numbers rather than invented ones. This chapter is the provenance record: where each piece of SKY130 data comes from, exactly which design rules are and are not checked, the explicit statement that passing them is not tape-out clean, and the license attribution for the standard-cell layouts committed as test fixtures.

Nothing here makes Reticle part of a SKY130 sign-off flow. It uses the PDK as a source of truth for values, so that when the editor, the agent harness, or the benchmark reports a measurement it is a real SKY130 number.

The technology stack and its source

The technology file tech/sky130.tech defines the digital metal stack: the drawing layers (nwell, diff/tap, poly, li1, and met1 through met5 with their contacts and vias), the pin and label purposes, and the physical z-height and thickness of each conductor for the 3D layer-stack view. It is a subset sufficient for the digital stack, not a complete SKY130 layer map.

The data is transcribed from the open SkyWater SKY130 documentation, cited in the file header:

• Layers (GDS layer:datatype): the SkyWater layers reference, generated from docs/rules/gds_layers.csv in the google/skywater-pdk repository.
• Process stack (z and thickness): the official Process Stack Diagram (docs/_static/metal_stack.svg) on the Criteria and Assumptions page.
• Units: SKY130 library GDS uses 1 database unit = 1 nm and 1 user unit = 1 um, verified by binary-parsing the UNITS record of sky130_fd_sc_hd__fill_1.gds. The technology file declares dbu_per_micron 1000 accordingly.

In the stack section, the conductor z and thickness values are read from the process stack diagram; contact and via slabs span the gap between the layers they connect. The well and active z-values are approximate substrate features (the diagram sets the silicon surface at z = 0) and are marked as approximate in the file. Those approximations affect only the 3D visualization’s substrate depiction, not any geometric check.

DRC rule subset

The DRC rules live in tech/sky130-drc-subset.toml, transcribed from the SkyWater SKY130 periphery rules (the Al flow, generated from docs/rules/periphery/periphery.csv in google/skywater-pdk) for the digital metal stack. reticle_drc::sky130_drc_rules() embeds that file at compile time and returns it as engine rules ready for DrcEngine::new. Values are in database units (1 dbu = 1 nm); areas are in dbu squared.

The full coverage table, with every rule id, kind, layer, value, and meaning, is in the SKY130 rule coverage chapter and is reproduced here so this grounding record is self-contained. Layer names follow tech/sky130.tech (GDS layer/datatype).

That is 26 rules: 12 width, 8 spacing, 3 enclosure, 2 area, 1 extension. The loader’s tests pin this count and the per-kind distribution, so the table above and the committed data cannot drift apart silently.

This is a subset, not tape-out clean

Passing this deck does not mean a layout is manufacturable. It is a fast, honest first filter over the everyday geometry mistakes (too narrow, too close, too small, under-enclosed, short endcap) against cited SKY130 values. It exists so the editor, the agent harness, and the benchmark can check real geometry against real numbers, not so a design can be signed off.

What the deck does not cover, including but not limited to:

• Antenna rules. No charge-accumulation checks at all.
• Density rules. No metal fill or min/max density windows (the engine has a density check kind, but this deck defines none).
• Latch-up and well rules. No nwell spacing or width, no tap-distance rules (tap.*, nwell.*), no butting rules.
• Implant and marker layers. nsdm/psdm/npc and friends are in the layer map but carry no rules here; most implant enclosure and spacing rules (nsd.*, psd.*, npc.*) are absent.
• Most contact and via rules. Sizes are encoded as min-width only (the real rules are exact-size), and only three enclosure directions are present; end-of-line, differential enclosure (m1.5, m2.5), array spacing, and licon-on-poly versus licon-on-diff distinctions are absent.
• Transistor-level rules. Gate spacing to licon, diff extension past poly (difftap.2, poly.7), and everything hvi/hv related.
• Resistor, capacitor, SRAM, sealring, and pad special-case rules.

Two engine caveats also apply (detailed in Design-rule checking): shapes are reduced to axis-aligned bounding boxes, which is exact for rectangles but conservative (it may over-report, never under-report) for polygons and paths; and same-layer spacing treats touching or overlapping shapes as merged rather than as a violation.

If a layout must be manufacturable, run the full SkyWater deck in a sign-off tool. This subset is a fast, honest first filter, nothing more.

Cell provenance and license attribution

Three standard-cell layouts from the SKY130 high-density library are committed as test fixtures and used as the geometry ground truth for tier-5 benchmark tasks. They are unmodified copies, attributed in crates/reticle-io/tests/corpus/sky130/NOTICE.md:

• Cells: sky130_fd_sc_hd__fill_1, sky130_fd_sc_hd__inv_1, and sky130_fd_sc_hd__tap_1 (a filler, an inverter, and a well tap: the smallest representative cells).
• Source: the google/skywater-pdk-libs-sky130_fd_sc_hd repository, upstream path cells/<name>/sky130_fd_sc_hd__<name>_1.gds.
• Version: fetched from branch main at commit ac7fb61f06e6470b94e8afdf7c25268f62fbd7b1 on 2026-07-02.
• Copyright: Copyright 2020 The SkyWater PDK Authors.
• License: Apache License, Version 2.0 (the library’s LICENSE; the same license text is included in this repository as LICENSE-APACHE).

The files are used as fixtures for the GDSII importer (tests/sky130_cells.rs) and the SKY130 DRC subset (tests/sky130_drc.rs). scripts/fetch-sky130-cells.ps1 re-fetches the full set, including the larger nand2_1 and dfxtp_1 used by an ignored external round-trip test (those larger cells are not committed).

Honest findings on the committed cells

The three cells round-trip through the importer with no importer gaps. Running the DRC subset over them is deliberately reported honestly: the filler cell is clean, while the tap and inverter flag a handful of li.5, li.3, and poly.8 results. Those come from the engine’s bounding-box conservatism and from the deck being an approximation of the full rules, not from the cells being illegal in the real PDK. This is documented rather than hidden, and it is exactly why the deck is described as a first filter and not a sign-off check.