PCells: cells with knobs

You need the same small shape in many sizes. A pad that is 50 by 30 micrometers on one part of the sheet, and 80 by 20 on another. A grid of squares with nine columns here and three there. Drawing each version by hand invents a family of almost-copies. A parameterized cell, or PCell, is the other habit: you keep a short list of knobs, and a script draws the cell when those knobs are set.

The picture at the top is a LayoutEditor teaching layout, not a device from a product. One generator idea, three parameter sets. On the left, a 3 by 3 grid of 2 micrometer squares with 1.8 micrometer gaps — the kind of cell a shipped square-array macro would name sqarray2_1.8_3_3_1, with a child cell square2_1 for the single square. In the middle, the same square size and gap, but 9 by 8 — sqarray2_1.8_9_8_1, the counts that ship as defaults in LayoutEditor’s Parametric Shape Library. On the right, still 9 by 8, but the gap grows to 4 micrometers and the squares sit on a second layer color — sqarray2_4_9_8_1. Same recipe. Different knobs. Different names, so the tool can find the matching geometry again without redrawing it.

Why it matters

Analog transistors, MEMS springs, photonic bends, and some via arrays share that pattern: a few numbers decide a whole drawing. Change width or finger count on a schematic, run schematic-driven layout again, and you want a matching layout cell — created if it is new, reused if those knobs already ran. LayoutEditor’s Components documentation puts it plainly: a static layout is a fixed cell; a parametric cell is built when needed from the device’s parameters, and a new matching layout cell is created or reused when the parameters change.

That is also why people write layout scripts. A script that places one named drawing on a pitch is the younger sibling of a PCell. The PCell wraps the same obedience in a library component: knobs on the symbol, geometry on demand, a stable cell name for each combination.

Process kits ship generators so every designer gets the same contact size and enclosure. Analog layout leans on them for devices that must match. MEMS and photonics lean on them for shapes that are tedious to redraw. The file stays editable because you edit the recipe or the parameters, not ten thousand copied polygons.

How it works

Knobs, a name, and reuse

In LayoutEditor the everyday generator is a macro — a .layout script. At the top you can declare defaults so the macro also runs without a schematic:

#parameter size "2µm"
#parameter space "1.8µm"
#parameterInt ny 8
#parameterInt nx 9
#parameter layer "1"

Inside main, iPar("size") reads the value: from the schematic device when schematic-driven layout ran the macro, or from that #parameter default when you execute the macro alone. The script builds a cell name from the knobs, checks whether that name already exists, and either selects the existing cell or draws a new one. The shipped square-array shape in the Parametric Shape Library follows exactly that pattern: one square cell, then an array of it at pitch size + space, with a nested sub-array when both counts reach ten thousand.

A LayoutScript version of the same naming and reuse, run against a real GDS on LayoutEditor, looks like this:

def ensure_square_array(d, size_nm, space_nm, nx, ny, layer=1):
    cellname = "sqarray%s_%s_%d_%d_%d" % (
        uu(d, size_nm), uu(d, space_nm), nx, ny, layer
    )
    if d.existCellname(cellname):
        d.setCell(cellname)
        return d.findCell(cellname)
    # else: create square child, then cellrefarray, name the parent

Same knobs return the same cell name (sqarray2_1.8_3_3_1). A wider space returns a new name (sqarray2_4_3_3_1). That is the whole cache: the name encodes the recipe inputs.

The second picture is one parameter set up close: five by four squares, still 2 micrometers on a side with 1.8 micrometer gaps. The teaching name is sqarray2_1.8_5_4_1. What you should see is not twenty inventions, but twenty instances of one square — the habit already explained in cells and instances. Edit the square cell, and every stamp changes. That is why the generator draws the primitive once and arrays it.

Where the generator lives

On a library component, the Layout tab says how schematic-driven layout should build the device. The first matching rule wins. A [macro] line points at a .layout file; after the macro runs, whichever layout cell is current becomes the device cell. The same dialog can also take layout from Tcl including Magic-style generators, from a gdsfactory callable, from an OpenAccess view, or from an external program that prints simple geometry lines on its output. Several methods can sit in one component with conditions. Availability of Tcl or gdsfactory depends on the LayoutEditor build and the process kit; the idea is the same: parameters in, named cell out.

Parameters themselves can carry units, tooltips, callbacks after a change, or formulas (parse=true) so one value is computed from another. Multiplicity factors and package pickers exist for flows that need them. None of that replaces a clear default and an honest cell name.

What ends up in the file

The third picture is the same idea with a rectangle generator: rect50_30_1 beside rect80_20_1 — width and height in the name, layer at the end, matching the shipped rectangle.layout style. What a GDSII file stores is still static geometry under those names: boxes, polygons, and references. The macro or Python that produced them is not inside the GDS. Keep the generator beside the layout in your design archive. When a contact size changes, you change the recipe and run it again; you do not hunt through flattened copies.

Before you send it to a shop

Mask writers and many lab exposure tools want frozen geometry. Guidelines from university nanofabrication labs that run direct-write tools ask designers to convert PCells to static cells, resolve arrays where required, and avoid shipping cell-context extras the tool mishandles. Keep an editable version with the generators. Ship an exposure version that is ordinary cells and shapes. If you edit the flattened ship file and leave the generator unchanged, the next regenerate quietly throws your patch away.

A common mix-up

One wrong picture is that a PCell is only a cell whose name looks parametric. A name like nmos_w2_l0.18 without a recipe behind it is labeling, not generation. The knobs have to drive code that builds or reuses the geometry.

Another wrong picture is that the editable generator file is what the fab should load. The fab wants the polygons. The generator is how you rebuild them when the circuit person changes a width.

A third is editing the expanded rectangles and expecting the next parameter change to keep the tweak. The recipe wins. Change the parameters, or convert to a static cell on purpose and own that freeze.

Things that go wrong

Units hide in plain sight. A script that means 2 micrometers and writes 2 in a file whose tick is a nanometer asks for 2 nanometers. Ten vias on that pitch pack into a smear; the measured shape in a LayoutEditor test of that mistake was one 0.168 by 0.150 micrometer rectangle instead of ten cuts. Write the unit next to the number. Macro helpers that parse "2µm" strings avoid that class of error when you use them.

Missing backends surprise people who open a library on a build without Tcl or without the gdsfactory worker the PDK expects. The component card still lists the method; the run fails later.

Huge arrays without hierarchy make heavy files. The shipped square-array macro builds a two-level array when both counts are at least ten thousand for that reason — the same pressure behind arrays and step-and-repeat and compact formats.

Two libraries with two almost-copies of a generator stop being twins. Lock the kit version the way you lock a rule deck.

In software

In LayoutEditor you meet PCells as library components with a Layout method, as macros you execute from the Text Editor or as Execute Macro, and as the Parametric Shape Library shapes that ship with the package — alignment marks, coils, meanders, square and dot arrays, and others aimed at MEMS and photonics work. The teaching path on this site is those macros and LayoutScript: #parameter defaults, iPar, a parameter-encoded cell name, and reuse. Other layout tools share the idea under their own APIs; some open kits expose Magic-style Tcl generators or gdsfactory cells that LayoutEditor can call when the bridge is installed. The craft point does not change. Knobs in, named static geometry out, generator kept in the archive, frozen cells for the shop.