OpenLane 2 on Sky130

A full run takes minutes to hours and most failed runs die in the first minute on something a file check would have caught. So: validate the config, run with a narrow scope, read the metrics, change one thing at a time.

Before starting a run

python3 scripts/check_config.py config.json --pdk-root ~/.volare

This checks the things that cost a whole run when wrong: paths that do not resolve, a CLOCK_PORT that is not a port of the RTL, a PDK family name where a variant is needed, a utilisation the router will not survive, and DIE_AREA set without FP_SIZING: "absolute", which silently does nothing.

A minimum viable config, with the parts that matter:

{
  "meta": { "version": 2 },
  "DESIGN_NAME": "my_design",
  "VERILOG_FILES": ["dir::src/my_design.v"],
  "CLOCK_PORT": "clk",
  "CLOCK_PERIOD": 20,
  "PDK": "sky130A",
  "FP_CORE_UTIL": 40
}

Three details that account for a large share of first-run failures:

• dir:: resolves paths against the config file. A bare relative path resolves against the working directory, so the run breaks the first time someone starts it from somewhere else.
• PDK takes a variant (sky130A), not a family (sky130).
• CLOCK_PORT has to be a real port of the top module. If it is not, static timing runs with no clock, every path passes, and you find out at sign-off.

A fuller starting config with the reasoning inline is in references/config-template.json.

Running

python3 -m pip install --upgrade openlane
python3 -m openlane --pdk-root ~/.volare config.json        # full flow
python3 -m openlane --to OpenROAD.Floorplan config.json     # stop early
python3 -m openlane --last-run --from OpenROAD.CTS config.json  # resume
python3 -m openlane --dockerized config.json                # pinned toolchain

--dockerized is the answer when a tool version is in question; the local install picks up whatever Yosys and OpenROAD happen to be on the machine.

Each step writes into its own numbered directory (05-yosys-synthesis, 31-openroad-globalrouting), so the step that failed names itself.

After a run

python3 scripts/summarize_run.py runs/          # newest run
python3 scripts/summarize_run.py runs/RUN_2026-09-21_10-00-00 --json

It reports where the run stopped, the tail of error.log, and the sign-off metrics with the out-of-bounds ones flagged. The metrics that decide whether a run is usable:

Sign-off is zero violations. A run with "only a few" DRC errors has not closed.

Reading a failure

Start from the failing step's own directory, not from error.log. The flow log carries what the flow surfaced; the tool log in the step directory carries the cause.

Stage-by-stage detail, the full step list, and the variables that matter at each stage are in references/flow-stages.md.

Working method

Change one variable per run. Two changes and a different outcome tells you nothing about which one mattered, and each experiment costs real time.

When a change only affects later steps, resume with --last-run --from <step> instead of re-running synthesis. Changing a synthesis variable invalidates everything downstream, so resume from Yosys.Synthesis in that case.

When utilisation is the problem, lower it. Raising GRT_ADJUSTMENT, PL_TARGET_DENSITY_PCT and routing layers to force a congested design through produces a run that completes and a design that fails sign-off.

Honest limits

check_config.py reads the config and the RTL as text. It does not elaborate the design, so it cannot tell you whether the top module is the one you meant, and its port extraction is regex-based and can miss ports declared through macros or include files. It does not validate PDK-specific variable names beyond the common ones.

summarize_run.py reads the metrics files the run wrote. If a step crashed before writing metrics, there is nothing to summarise and it says so rather than guessing.

Neither script is sign-off. Magic DRC, Netgen LVS and post-PNR STA are the authorities, and a shuttle programme will run its own checks on top.