Every stage of the flow in lesson 2 reads data that the design team did not write: the rules of the manufacturing process, models of its transistors and wires, and libraries of pre-designed cells. This data arrives from the foundry and from library providers, in many files and many versions, and the flow team is usually the group that installs it, points the flow at it, and keeps track of which version every block used.
This lesson describes what is inside a process design kit (PDK), how one standard cell exists as several views for different tools, and how design data is kept under version control with a directory layout that makes runs reproducible.
Reading time: about 7 minutes.
5.1 What is in a PDK
A process design kit is the package a foundry provides so that designers can build circuits for one particular process. Its contents vary from foundry to foundry, but the main parts are similar everywhere.
| Component | What it describes | Main consumers |
|---|---|---|
| Design rule manual | Human-readable rules: widths, spacings, enclosures, densities | Designers, rule-deck reviews |
| Technology LEF / tech file | Routing layers, directions, pitches, vias, placement sites | Place-and-route |
| DRC, LVS, antenna rule decks | The rules in a form the verification tool can execute | Physical verification |
| Extraction technology files | Layer thicknesses, dielectric constants, resistivity, for RC extraction | Extraction, sometimes PnR |
| Device models (SPICE) | Transistor, resistor and capacitor models at process corners | Circuit simulation, library characterisation |
| Layer map | Mapping from layer names to GDS layer and datatype numbers | Stream-out, verification |
| Standard-cell and IO libraries | Pre-designed cells in all their views (section 5.2) | Every implementation stage |
Strictly, the standard-cell, IO and memory libraries are often delivered separately from the PDK, by the foundry or by a third-party IP provider. In daily speech the whole set is frequently called "the PDK", and this lesson keeps that usage. The open SKY130 PDK, for example, ships its standard-cell libraries (such as sky130_fd_sc_hd) alongside the technology files, which makes it a convenient reference for the mini-flow in lesson 10.
5.2 One cell, many views
Let us consider a single two-input NAND cell. The synthesis tool needs to know its function and its delay; the placer needs its size and pin positions; the verification tool needs its full layout and its transistor netlist. No single file format carries all of this, so the library provides the same cell in several views, each one tailored to the tools that read it.
Two of these views multiply. Liberty files exist once per PVT corner – process, voltage and temperature – because delay depends on all three. SKY130's high-density library, for example, includes files named like sky130_fd_sc_hd__tt_025C_1v80.lib (typical process, 25 °C, 1.80 V) and sky130_fd_sc_hd__ss_100C_1v60.lib (slow process, 100 °C, 1.60 V). Device models and extraction files similarly come in several corners. A flow therefore never asks for "the library" but for the library at a named corner, and that name belongs in the configuration file (lesson 3), not in a script.
Because the views come from different generation steps, they occasionally disagree. It is prudent for the flow to run simple consistency checks when a library is installed: every cell in LEF has a Liberty model, pin names match, and areas agree. Lesson 9 returns to checks of this kind.
5.3 Version control for design data
Design data falls into two groups, and each needs a different treatment.
Source data
RTL, SDC, UPF, flow scripts, configuration files and Makefiles are text written by people. They belong in an ordinary version control system, and today that is usually git. Every change has an author, a message and a history, and any earlier state can be recovered.
Generated and large binary data
Netlists, native databases, SPEF and GDS are generated by the flow and can be hundreds of megabytes or more. Storing every version of them in plain git makes the repository slow, because git keeps full history of every file. Three approaches are common:
- Do not store it; regenerate it. If source data, tool versions and the flow are all recorded, any generated file can be rebuilt. This is the cleanest option for intermediate results.
- Git LFS (Large File Storage). Large files are replaced in the repository by small pointer files, and the content is kept on a separate server. A pattern is registered with a command such as
git lfs track "*.gds", which writes a line to.gitattributes. This suits a modest number of release files, such as hard-macro GDS and LEF. - Design data management (DM) systems. Commercial DM tools are built for chip data. At concept level they add what plain git lacks for this use: file locking for binary data that cannot be merged, workspaces that link to shared copies rather than duplicating them, and hierarchical releases in which a chip-level release refers to fixed releases of each block and library.
Whichever system is used, the essential rule is the same: every result must be traceable to an exact version of source data, flow, tool and PDK.
5.4 Directory and run conventions
A directory layout is a methodology decision, because every script depends on it. One common shape is shown below.
/tools/pdk/sky130A/ # installed, read-only
/tools/lib/sky130_fd_sc_hd/v0.0.2/ # versioned, read-only
/proj/chipA/
flow/ # stage scripts, wrappers (git, tagged releases)
blocks/aes_core/
rtl/ constraints/ config/ # source data (git)
Makefile
runs/
2026-11-04_base/ # one directory per run
2026-11-05_dens65/
syn/ place/ route/ sta/
run_info.json # tool, flow, PDK versionsThree conventions carry most of the value. First, installed PDKs and libraries are read-only and live in a versioned directory, so that a new release never overwrites an old one that a block still uses. Second, each run has its own directory, so that two experiments never write over each other. Third, every run records the versions it used in a small file such as run_info.json, written by the wrapper from lesson 3. Lesson 7 reads these files when it compares runs.
Assumptions: the library provider releases version v0.0.3 of the standard-cell library with recharacterised Liberty files. The project currently uses v0.0.2.
- The CAD team installs v0.0.3 into its own directory beside v0.0.2. Nothing that points at v0.0.2 changes.
- Consistency checks run on the new release: cell lists, pin names and areas compared between LEF and Liberty.
- A configuration branch points a set of reference blocks at v0.0.3 and the regression (lesson 8) runs them.
- QoR tables (lesson 7) compare the two versions. If timing moves, the Liberty differences explain why.
- The project decides when blocks switch, and each block's
run_info.jsonrecords which version its signoff used.
At no point is a library edited in place. That is what makes step 5 meaningful.
5.5 Interview questions
What does a PDK contain? Typically the design rule manual, technology LEF or tech files, DRC, LVS and antenna rule decks, extraction technology files, SPICE device models at corners and a layer map, often accompanied by standard-cell and IO libraries.
Why does one standard cell have several views? Each tool needs different information. Liberty gives timing and power, LEF gives the abstract for placement and routing, GDS gives the full layout for stream-out and DRC, CDL gives the transistor netlist for LVS, and Verilog gives function for simulation.
Why not store GDS and databases in plain git? They are large binary files that cannot be merged, and git keeps their full history, so the repository grows quickly. They are usually regenerated, stored with git LFS, or managed with a DM system.
Why are installed PDKs kept read-only and versioned? So that a new release never changes results of blocks that still use the old one, and every run can record and later reproduce the exact version it used.
Key takeaways
- A PDK holds the process rules, rule decks, device models, extraction data and layer map; cell libraries usually accompany it.
- Each cell exists as several views – Liberty, LEF, GDS, CDL, Verilog, test model – and the views must agree.
- Liberty, device models and extraction files come per corner, so the flow always names a corner in configuration.
- Source data lives in git; large generated data is regenerated, kept in git LFS, or handled by a DM system.
- Read-only versioned installs, one directory per run, and a recorded version file per run make results reproducible.