Installing OpenLane and the SKY130 PDK

Everything up to now has been safe to read without a terminal. This article is not, and it should not be. Physical design is a hands-on discipline, and the rest of the course assumes a working OpenLane and SKY130 install on your own machine. This article gets you there.

Why Docker

OpenLane’s dependency list is long: Yosys, OpenROAD, Magic, Netgen, KLayout, and every library each of those needs, at compatible versions. Installing all of that natively on an arbitrary machine is exactly the kind of fragile, version-conflict-prone process that wastes a beginner’s first week before a single design runs. OpenLane sidesteps it by shipping as a Docker-based flow: the tools live in a container image, built once and used identically everywhere, and your host only needs Docker plus the OpenLane repository’s scripts.

Installing OpenLane

git clone https://github.com/The-OpenROAD-Project/OpenLane.git
cd OpenLane
make

git clone pulls the OpenLane repository: the orchestration scripts, sample design configs and Makefile targets that drive everything. make does the real work: it pulls or builds the Docker image containing the five tools at pinned compatible versions and sets up the local scripts that invoke the container.

A successful make ends with the tool ready to accept a design. To confirm the install works, run OpenLane’s own test target:

make test

This runs a small, known-good sample design through the complete flow and reports pass or fail. Seeing it complete with a GDSII produced is your first confirmation that the whole toolchain is installed correctly, before you point it at your own RTL.

Installing the PDK with Volare, and why the version matters

OpenLane needs the SKY130 PDK installed separately from the tools. As Section 1.3 said, the PDK is data (models, libraries, rule decks), not a tool. Volare is the PDK version manager for exactly this: it downloads and manages specific tagged versions of the PDK and lets you switch between them.

pip install volare
volare enable <pdk-version>

volare enable <pdk-version> downloads (if not cached) and activates one specific named version of the PDK. <pdk-version> is a real version identifier, not something to leave literally in the command.

The parallel to pinning a software dependency, a requirements.txt or package.json pinning an exact version instead of “latest”, is deliberate, and for the same reason: reproducibility. A PDK changes over time as its maintainers fix bugs, add cells or refine rules. A design built and signed off against one PDK version is not guaranteed to be identical, or even DRC-clean, when re-run against a newer version, because cell characterisations, rule decks and even cell geometry can change between releases. Every real tapeout pins an exact PDK version for its whole duration, to avoid a design that was clean last month silently becoming non-clean this month for no reason anyone touched.

So: always know, and record, the exact PDK version tag a run used. Later modules assume you can answer “which PDK version produced this result?” at any point.

Confirming the install

Once both steps complete, confirm the PDK is enabled and visible:

volare enable <pdk-version>
ls $PDK_ROOT/sky130A

A successful install shows a populated sky130A directory, containing among other things the library variants from the previous article (sky130_fd_sc_hd, sky130_fd_sc_hs and others), the SPICE models and the rule decks. Seeing those subdirectories is the on-screen confirmation that everything Section 1.3 described is now real data on your disk.

Practice Exercise

You install OpenLane and the PDK today, run several designs, and leave the install untouched for six months. A teammate joins, follows a slightly outdated guide, and runs volare enable without a version, getting whatever the current default is. Explain the risk.

With a working install, the next article tours the OpenLane directory structure, where designs, the PDK and run outputs live, and has you build your first design folder by hand.