What a PDK actually contains

You need a factory to build what you drew — a tiny amplifier, a digital blinker, a pad ring. Pretty colors on the screen are not enough. You need the factory’s dictionary: which number means metal, which shapes are legal, which ready-made cells exist, and which electrical models the simulator may trust. That package is a process design kit, or PDK.

This picture is a teaching neighborhood, not a taped-out chip. A pale n-well tub holds two device regions. Green active with implant markers, gold poly gates, orange contacts, teal metal1 straps, and a blue metal2 bus with vias stack the way a real process stacks films. Labels such as nwell, poly, metal1, and via1 are the kit’s vocabulary painted onto geometry. A layout editor that “opens on the PDK” populates a layer list like this so you are not inventing sheet names in the dark.

Why it matters

This lesson is electronics headed for a foundry (the board-house cousin is thinner and appears later). Without a kit matched to the process you will buy, layer numbers are rumors. Your teal rectangle might be metal1 in one factory’s map and something else in another. Design-rule checkers and circuit checkers need recipes from the same kit. A beautiful file drawn against the wrong kit can look professional and still be illegal, electrically wrong, or simply meaningless to the mask shop.

A concrete miss: you recycle a handy via cell from an older project into a new process. The via’s shapes still sit on layer 31. In the old kit, 31 meant metal1. In the new kit, 31 means poly. The screen may still look tidy if your local colors were never updated. The factory will not merge your optimism.

Industry packages the kit early because fabless work is a handshake. The foundry publishes one process variation; customers design, simulate, draw, and verify against that package; an accurate kit raises the odds of first-pass silicon. Open kits and commercial kits share the same idea even when their folder trees differ.

How it works

A PDK is not one file. It is a bundle of roles.

Layer map and technology data are the dictionary. Formats such as GDSII store geometry on numbered layers (and often a datatype). The kit says what those numbers mean for this process — metal1, poly, n-well, drawing-only keep-out — and may ship display colors and fills so colleagues share a habit. Color is still local fashion; the number-plus-map is the contract. Process sheets versus documentation sheets are a deeper fork taught in process layers versus drawing layers. Numbers and datatypes are unpacked in GDS layer and datatype.

Design rules and verification decks are the grammar and the checker scripts. A human-readable design-rule manual (often a PDF) states minimum widths, spaces, enclosures, densities, and stranger rules. Machine-readable decks drive design rule checking (DRC) — a spellchecker for legal geometry — and layout versus schematic (LVS), which asks whether the drawing is still the circuit. Antenna, electrical-rule, and extraction decks often travel with them. Rules are not suggestions; the kit is where those sentences live as both prose and scripts.

Device and cell libraries are the furniture catalog. Primitive devices and parameterized cells (PCells) let you place transistors and passives with legal defaults. Digital flows add standard-cell libraries, I/O pads, and macros. Each library usually ships several views for different jobs: full layout (often GDS), abstract LEF for place-and-route, Liberty timing and power tables for synthesis and timing analysis, SPICE or CDL netlists for simulation and LVS, Verilog for digital simulation. Open kits often separate technology/setup files from these reference libraries; commercial kits may use different trees. The teaching point is the roles, not a path on disk.

Simulation models are the behavior the simulator trusts — SPICE-class models for transistors and passives in electronics, with process-voltage-temperature corners. Photonic kits swap in optical building blocks and S-parameter-style models; more on strips of light in waveguides are paths with feelings.

Documentation and version pins close the bundle. Release notes, application notes, and the design manual settle arguments when a deck is stale. Pin the revision in the project (pdk-180-rev4 as a habit). Mixing rev4 devices with a rev3 rule deck is a classic tapeout scare.

Numbers keep the dictionary honest. Suppose the kit’s layer map says metal1 is GDS layer 31, datatype 0, with a minimum drawn width of 0.14 µm. If the database stores 1000 ticks per micrometer, that minimum is 140 ticks. Your editor may paint 31 teal because the kit’s display file said so; a colleague may use orange for 31. Both are fine if the number matches the kit. Swap to another process’s map where 31 means poly, and the same file becomes a polite lie.

The body figure is the same teaching transistor twice. On the left, the kit map is honest: teal straps and rail are metal1; the gold finger is poly; green active and orange contacts sit where the process expects them. On the right, the polygon coordinates are unchanged, but metal shapes wear the poly color and name — metal drawn as poly. That is what a wrong layer map does to a drawing: the geometry did not move; the dictionary did.

When you open a new library “on” a PDK in an editor, expect the layer list to fill, legal PCells to appear, and rule decks to become runnable — if those pieces were installed for your tools. The kit is the handshake; the tools are the hands.

A common mix-up

Beginners treat the PDK as if it were the chip — a GDS to ship. It is the dictionary and the furniture catalog, not the product. Another mix-up is believing any layer map will do because the screen still looks colored. Colors are costumes. The map is the script.

A quieter cheat is mixing two kits in one file because a via cell looked handy. Layer 31 in kit A is not layer 31 in kit B. The mask shop will not merge your optimism. Scripts that hard-code layer numbers without naming the kit revision inherit the same trap — which is why people write layout scripts carefully once numbers become policy (why people write layout scripts).

Things that go wrong

Wrong process kit: geometry that is legal for factory A and illegal or meaningless for factory B. Wrong revision: rule deltas, model corners, and cell footprints drift while the team still says “the 180 nm kit.” Missing layer map: everyone invents local names; DRC and LVS cannot attach process meaning. Stale deck versus fresh PDF: the manual still wins arguments — update the deck or stop claiming signoff. DRC “clean” on the wrong rules is a false calm. LVS with the wrong extract recipe makes devices vanish or multiply.

Board houses often ship a thinner cousin: a stackup plus a footprint library. Same social idea — speak the factory’s language — fewer views. Tiny moving machines (MEMS) often lean on a design handbook and process notes more than a full CMOS-style kit, because custom structures are hard to pre-characterize like a standard transistor; see MEMS is layout plus a recipe. Photonic PDKs keep the kit structure and change the physics: the “transistor” may be a bend.

In software

Layout editors (including LayoutEditor) load technology display settings, layer maps, and cell libraries so you can draw and view. They are not themselves a foundry PDK, and they do not replace foundry signoff decks. Signoff flows run DRC and LVS engines against the kit’s rule files; open flows consume the same roles with different tool formats. This page does not rank vendors. Every serious tapeout needs the kit that matches the process you will build — version pinned — not a folder that merely looked similar.