topics: [“openlane”, “asic”, “eda”, “python”, “nix”]
After running OpenLane1 (the Docker-based flow) once,
the same questions inevitably arise:
In this article, OpenLane2 is positioned as:
Not a “new OpenLane,” but a separately redefined flow infrastructure
designed for engineers who actively manage and evolve their design flows
Let us first clarify the relationship.
Neither is superior, nor is one a successor to the other.
They simply serve different purposes.
With OpenLane1, the following become difficult:
OpenLane2 is designed explicitly to enable these capabilities.
The core focus of OpenLane2 is control over the design environment
OpenLane2 is distributed as a Python package.
This choice aligns with use cases such as:
👉 There is a clear design stance here:
Python is a control language, not an EDA tool
This point is often misunderstood, so it is worth stating clearly.
In other words, OpenLane2 is characterized by:
Not being tied to a single installation method
In practical examples such as openlane2-sram,
a different operational choice is made:
This approach is chosen in order to:
venv is not the “official one true way,”
but one practical implementation prioritizing coexistence and isolation
| Perspective | Docker | Nix / venv |
|---|---|---|
| Environment fixation | Strong | Selective |
| Reproducibility | High | Extremely high (Nix) |
| Flow modification | Difficult | Easy |
| Designer-oriented | △ | ◎ |
This difference reflects the philosophical divide
between OpenLane1 and OpenLane2.
OpenLane2 shows its strengths in scenarios such as:
Conversely, for cases like:
OpenLane1 is the better choice.
This point is critical and must be stated explicitly:
OpenLane2 is not a successor to OpenLane1.
It is a parallel lineage created for role separation.
Using each where it fits best is the healthiest approach.
Once you start using OpenLane2,
you inevitably reach the next set of questions:
In the next article, we will organize:
The implicit assumptions OpenLane makes about PDKs
Why GF180 Open PDK is harder to apply
from the perspective of design prerequisites.
OpenLane2 is a tool for:
Moving from “running a flow”
to actively “operating and evolving” the design process