What a PDK Contains
Section 1.2 was about the tools. Section 1.3 is about the data every one of them needs.
Yosys needs to know what standard cells exist to synthesize into. OpenROAD needs each cell’s footprint to place it and its timing to time it. Magic needs the spacing and width rules to check DRC. None of the tools invents any of this. It all comes from one source, the PDK.
A PDK is a contract
A Process Design Kit is a fab’s formal description of two things: what its process can physically build, and the set of files and formats a designer must use to describe a design for it. It helps to think of a PDK as a contract between what you are allowed to design and what the fab can manufacture. Every rule and every model in it reflects a real physical or economic limit of that fab’s process.
A PDK bundles several kinds of content:
- SPICE device models: the electrical behaviour of the process’s transistors, resistors and capacitors, for circuit-level simulation.
- Standard cell libraries: pre-designed, pre-verified logic cells (inverters, NAND gates, flip-flops and so on), each provided in several views, as described below.
- I/O cell libraries: cells for getting signals on and off the chip safely (pad drivers, ESD structures), a different design problem from internal logic.
- DRC and LVS rule decks: the tool-readable rule files that Magic, KLayout and Netgen load and check against.
One cell, several views
This is the detail to internalise early, because it explains a recurring pattern across the course: a single standard cell, say a 2-input NAND, is not described by one file. It is described by several, each a different view of the same cell, because different tools at different stages need different information about it.
| View | File type | What it describes | Used by |
|---|---|---|---|
| Timing | Liberty (.lib) |
Delay, setup/hold, power, as a function of input slew and output load | Synthesis (Yosys), timing analysis (OpenSTA) |
| Physical abstract | LEF (.lef) |
Pin locations, cell footprint, no internal detail | Placement, routing (OpenROAD) |
| Layout | GDS (.gds) |
The mask polygons for the cell | GDSII streamout, physical verification (Magic, KLayout) |
| Schematic | SPICE (.spice) |
Transistor-level netlist of the cell | Circuit simulation, LVS reference |
The multi-view pattern is the standard cell library’s version of the abstraction stack from Section 1.1. A synthesis tool reasoning about timing does not need a NAND gate’s polygon shapes, and a router placing that NAND does not need its timing model. Each tool gets the view it needs and nothing more.
Matching files to stages
A PDK install directory contains files with extensions like .lib, .lef, .gds and .spice, plus DRC and LVS rule decks (a .tech file for Magic, and other formats for other tools). Before running any tool, match each to the stage that opens it:
.lib: read by Yosys during synthesis, and by OpenSTA at every timing checkpoint from Module 2 on..lef: read by OpenROAD during floorplanning, placement and routing, which need footprints and pin locations but nothing about timing or internal geometry..gds: read by KLayout for viewing, and produced as the final output of Module 9’s streamout..spiceand the rule decks: read by Netgen (LVS reference and rules) and Magic and KLayout (DRC rules) during Module 8’s physical verification.
Noticing which stage reaches for which file, before running anything, previews where each view reappears later. It also helps in debugging: when a design “won’t synthesize” for a missing library, or “won’t place” for a missing LEF, the bug is almost always a PDK path or setup problem, not the RTL, and the view the error names tells you which part of the setup to check. One related trap: a Liberty file and a GDS file are versioned artefacts that have to come from the same PDK release. Mixing a .lib from one release with a .gds from another is a real, avoidable source of subtle bugs, which is one reason the version pinning in Section 1.4 matters.
Practice Exercise
A colleague says: “I don’t need the LEF for a cell, I already have its GDS. The GDS has the actual geometry, so it has everything.” What is wrong with skipping the LEF?
Solution
The GDS does contain the full geometry, but it is the wrong representation for what placement and routing need quickly and repeatedly. A LEF is a lightweight abstract: pin locations and the cell’s outer boundary, deliberately stripped of internal detail, so that placement and routing can reason about thousands of instances without parsing full mask geometry for each one. Using GDS for placement and routing would work in principle but would be far slower, and would expose internal cell geometry to a stage that has no reason to see it. LEF exists so the placement and routing stage gets the small, fast view it needs, while GDS remains the large, complete view for the stages that need geometry.
In the next article we get specific about the process this course targets: SKY130, a real, fabricable, open 130 nm process, and why that makes it a good teaching target rather than a toy.