LibreLane: driving an open-source ASIC implementation flow from Python

An implementation flow infrastructure, not a design suite

LibreLane is described as an infrastructure library that enables the construction of digital implementation flows for application specific integrated circuits based on open-source and commercial EDA tools. The repository calls itself the successor to OpenLane, and the licence file, the maintainer list and the FOSSi Foundation trademark all place it in the open chip design ecosystem rather than in the commercial EDA world.

That distinction is the whole point. The tool that synthesises your Verilog, places and routes it, and writes out a GDSII or a netlist is not the interesting part for most users; the interesting part is knowing which tool to run, in which order, with which options, and being able to repeat that exactly six months later. LibreLane is the layer that encodes that knowledge, and it calls itself infrastructure for that reason.

The audience is concrete. A student who wants to see a full flow run on a laptop, a research group comparing floorplanning strategies, or a small team that wants a reproducible baseline before committing to commercial tools all land in the same place. What they get is a configuration file, a set of steps, and a tool environment that is packaged and versioned.

The project is Python, requires Python 3.10 or higher, is licensed Apache-2.0 with one exception that matters later, and the last push to the repository was on 2026-10-20. The recent releases are 3.0.16 from 2026-10-06, 3.0.15 from 2026-10-05 and 3.0.14 from 2026-09-06, a patch cadence that shows the 3.0 line is being maintained.

The Python API: a flow object, a config dict, one call

The README's front page example is short, and it shows the shape of the whole programming model.

from librelane.flows import Flow

Classic = Flow.factory.get("Classic")

flow = Classic(
    {
        "PDK": "sky130A",
        "DESIGN_NAME": "spm",
        "VERILOG_FILES": ["./src/spm.v"],
        "CLOCK_PORT": "clk",
        "CLOCK_PERIOD": 10,
    },
    design_dir=".",
)

flow.start()

A flow is fetched from a factory by name, instantiated with a configuration dictionary and a design directory, and started. The configuration keys are the knobs a chip designer actually turns: which process design kit, which design, which Verilog files, which clock port and what clock period in nanoseconds.

Two things are worth noticing. The first is that the same configuration is expressed as a plain dict, which means the flow can be driven from a script, from a notebook, or from a configuration file, and that the repo carries a `notebook.ipynb` at the top level, along with a Colab badge in the README, so the browser is a supported way in. The second is the `Flow.factory.get("Classic")` call, which shows that flows are looked up by name rather than imported directly, and that there is a registry of flows behind that name.

There is more than one such name. The README says LibreLane includes two reference flows, Classic and Chip, both built entirely using open-source EDA tools. The naming suggests an older and a newer generation of flow, and the `Classic` reference in the example is a signal that a new user is expected to pick one deliberately rather than get a default.

The same registry idea shows up in the console scripts the project installs, which are separate entry points for the flow, the steps, the configuration, the state, the help system and the environment information.

Three installation routes, and one the project tells you to avoid

The installation section is where the project's opinion shows. You need Python 3.10 or higher with pip, venv and Tkinter, and then there are three routes.

The recommended one is Nix, which works for macOS and Linux on x86-64 and aarch64, and the README gives the reason: it is more integrated with your filesystem and overall has less upload and download deltas. The project is built with Nix, the repository carries `flake.nix`, `flake.lock`, `default.nix` and `shell.nix`, and a `nix/` directory, so this is a first class path rather than an afterthought.

The second is Docker, which works for Windows, macOS and Linux on the same two architectures. There is a caveat that affects every command you will type, and it is easy to miss: you need to add `--dockerized` right after `librelane` in most CLI invocations.

The third is the Python-only installation, which the README marks as advanced and not recommended, because you will need to bring your own compiled utilities.

python3 -m pip install --upgrade librelane

The README then adds the sentence that should stop most people: Python-only installations are presently unsupported and entirely at your own risk. That is an unusual thing to find in an installation section, and it is a real signal about the intended deployment model. The tool assumes a hermetic, packaged environment of EDA binaries, which is exactly what Nix and Docker provide and what a plain pip install does not.

The Makefile reinforces the same message. Its `mount` target prints that make mount is not needed in LibreLane and that you may simply call librelane --dockerized, and the pdk targets print that LibreLane will automatically pull PDKs and or Docker containers when it needs them. The environment assembles itself.

Running a flow from the command line

The usage section is two commands, and the second one is the one a first-time user will run.

python3 -m librelane --pdk-root <path/to/pdk> </path/to/config.json>

The invocation takes a PDK root and a configuration file, and the repository root is the place from which you invoke it. The concrete suggestion is the following, which points at a PDK under the home directory and at a configuration file in the repository.

python3 -m librelane --pdk-root $HOME/.ciel ./designs/spm/config.json

The `$HOME/.ciel` path is worth a moment of attention, because it names the tool that fetches process design kits. The ciel package appears in the runtime dependencies with a version constraint, and it is the mechanism by which a PDK ends up on your machine. The Makefile echoes this with the message that LibreLane will automatically pull PDKs and or Docker containers when it needs them, so the PDK root is a cache location rather than something you assemble by hand.

The `spm` design name in the example appears in both the command and the Python example, which tells you the repository ships a small example design with a `designs/spm/config.json` to run. That is the fastest way to see the flow work end to end before pointing it at your own Verilog.

The dependency list also hints at what the tool does around the EDA binaries. `click` and `cloup` provide the command line interface, `rich` the terminal output, `pyyaml` the configuration parsing, `klayout` the layout handling, `lxml` the XML work that Verilog and netlists require, `httpx` the network access, `psutil` the process and resource monitoring, and `semver` the version handling. `lln-libparse` and `deprecated` and `yamlcore` are more specialised, and `rapidfuzz` suggests matching or fuzzy comparison of names and versions somewhere in the step or configuration machinery.

Hermetic snapshots, reproducible environments and ECOs as steps

Five properties are claimed in the README, and three of them are about trust rather than convenience.

Hermetic is the first. The description is that you can rewind and explore alternative configurations without losing data, because LibreLane captures explicit snapshots of the configuration and state of your design at every step. That is a design decision with real consequences: it means the tool records enough about each step that a configuration can be reconstructed, which in turn is what makes the next property possible.

Reproducible and traceable comes next. The stated goal is same tools, same flow, same configuration, same result, and the mechanism is that LibreLane comes packaged with a verified environment of free EDA utilities. The documentation angle follows: capture your modifications and engineering change orders, or ECOs, as automated steps, and make your flow your documentation. A flow that is described as a sequence of recorded steps is a flow that another engineer can read.

The other two properties are about use rather than trust. Simple to use means configuring the entire ASIC implementation flow using one file, which is the point of the configuration dictionary in the example. Flexible and extensible means creating custom flows, either by simple modifications to the default flows in the configuration file, or by writing Python scripts or plugins to implement advanced functionality. The plugin mechanism is the reason the project can absorb new EDA tools without a rewrite.

Free and open source is the fourth, and its formulation is unusually specific: a complementary set of open-source process design kits, the ability to design and implement a chip without signing a single document, and the freedom to modify the infrastructure, the underlying tools and the PDK. The phrase about not being a vendor is doing the real work there, because it distinguishes this from a commercial flow that ships binaries you cannot change.

OpenLane heritage, a two-flow model, and a fixed example design

The lineage matters for anyone arriving from OpenLane, because the two projects are related but not interchangeable.

The README states that LibreLane is based on OpenLane 2 by Efabless Corporation, with assets owned by UmbraLogic Technologies LLC, and the project carries that company's Apache 2.0 copyright notice. So the heritage is the second generation of OpenLane, not the original, and the reference flows named Classic and Chip sit inside that generation.

The citation the project asks users to make is about OpenLANE rather than LibreLane. It asks that you cite the paper on building OpenLANE, a 130nm OpenROAD-based tapeout-proven flow, presented at ICCAD 2020 by Shalan and Edwards, and the BibTeX entry is provided so that a paper can reference it consistently. The implication is that the flow LibreLane implements is the one that paper describes, and that the citation of record for the method is still the OpenLANE paper.

The example design deserves a mention too, because it is a fixed point in the documentation. The `spm` design appears in the Python example and in the command line example, with the same clock port and period, so the design and its configuration travel together through both entry points. A newcomer can therefore diff a script against a file and see that they are the same configuration expressed twice.

Other signs of a serious project surround the core. The repository has a `Changelog.md`, a `SECURITY.md`, a `CONTRIBUTING.md`, an `Authors.md`, a `Makefile` with lint, coverage and license check targets, a `test/` directory, `type_stubs/`, a `.coveragerc` and a second `.coveragerc-steps` for the step layer, a `flake8` configuration and a `mypy` configuration. The lint target is three commands, black for formatting, flake8 for style, and mypy for types, which tells you the code is expected to be typed and formatted to a fixed standard.

Two licences, one branch policy, and the case for not using it

The legal picture has one wrinkle that a reader should know about before distributing anything.

LibreLane code and binaries are available under the Apache License, version 2.0, except for the Nix language files ending with `.nix`, which are under the MIT License. In a repository with `default.nix`, `flake.nix`, `shell.nix` and a `nix/` directory, that is a meaningful slice of the tree, and the split exists because the FOSSi Foundation wanted the Nix packaging to stay permissively licensed. The LibreLane name and logo are trademarks of the FOSSi Foundation, and the logo itself was created by Jon Walters, so the trademark and the artwork have their own terms, and the logo is not covered by the code licence at all.

The branch policy is stated in a tip block in the README. The `main` branch is the stable branch, updated less frequently and accepting only bugfixes, and feature contributions should be directed towards the `dev` branch. That is a mature convention and it has a practical consequence for contributors: a pull request against main will be closed or redirected, and the release tags come from main, so the versions you install are the conservative ones.

The case against using LibreLane is real and should be stated plainly. An open-source flow can take a design all the way to a tapeout, but the moment a design needs a proprietary PDK, a commercial sign-off tool, or a foundry-specific verification flow, the open path ends and the cost of the toolchain changes shape entirely. The README's own promise, designing and implementing a chip without signing a single document, is exactly what you give up when you need a commercial PDK. Teams that have already committed to a vendor flow will find the Python configuration model a pleasant change of pace and nothing more.

The second wrong case is operational. The recommended installation assumes Nix or a container, and the Python-only path is described as unsupported and entirely at your own risk. A CI image that cannot run containers or Nix is not a supported configuration, and the tool will be pulling PDKs and container images on demand, which is a network dependency your build system has to account for.

Editorial conclusion

LibreLane is a good fit for a student, a research group or a small team that needs to run a complete open-source ASIC flow today, to teach the flow without a commercial licence, or to script a custom flow on top of open tools. It is the wrong choice for a tapeout that depends on a proprietary PDK and vendor sign-off, and for anyone who cannot host a container or a Nix store. Verify first which PDK your design needs and that the ciel tooling can supply it, since the example configuration names sky130A and the flow pulls PDKs automatically, then read the licence split before you redistribute anything, because the Nix files are MIT while the rest of the project is Apache-2.0.

Frequently asked questions

Official sources

1. librelane/librelane on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases