【Semiconductor】🧩 13. OpenLane2

— Why Python-Based? Organizing Nix Recommendation, Docker Support, and venv Usage

topics: [“openlane”, “asic”, “eda”, “python”, “nix”]

🧭 Introduction

After running OpenLane1 (the Docker-based flow) once,
the same questions inevitably arise:

• Why does a separate lineage called OpenLane2 exist?
• Why is it a Python package?
• Isn’t Docker sufficient?

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

🔁 Relationship Between OpenLane1 and OpenLane2

Let us first clarify the relationship.

• OpenLane1
  • Docker-based
  • Education / Proof-of-Concept oriented
  • An environment to experience the flow “end to end once”
• OpenLane2
  • Python-based
  • Design / research oriented
  • An environment to manage, parameterize, and restructure flows

Neither is superior, nor is one a successor to the other.
They simply serve different purposes.

🎯 What Problem Is OpenLane2 Trying to Solve?

With OpenLane1, the following become difficult:

• Reassembling the flow programmatically
• Iterative execution under varying design conditions
• Systematic integration of macros (e.g., SRAM)
• Managing the design environment itself

OpenLane2 is designed explicitly to enable these capabilities.

The core focus of OpenLane2 is control over the design environment

🐍 Why OpenLane2 Is Python-Based

OpenLane2 is distributed as a Python package.

This choice aligns with use cases such as:

• Treating flows as code
• Structuring design constraints and configurations
• Performing experiments, comparisons, and automation

👉 There is a clear design stance here:

Python is a control language, not an EDA tool

📦 Officially Recommended Installation Methods (Important)

This point is often misunderstood, so it is worth stating clearly.

Official OpenLane2 Stance

• Nix is recommended
• Docker is also supported
• Distributed as a Python package (via pip)

In other words, OpenLane2 is characterized by:

Not being tied to a single installation method

🧪 What venv-Based Operation Means (Position of openlane2-sram)

In practical examples such as openlane2-sram,
a different operational choice is made:

• Use a Python virtual environment (venv)
• Run OpenLane2 locally in an isolated manner

This approach is chosen in order to:

• Avoid breaking an existing OpenLane1 setup
• Share PDKs across environments
• Safely experiment with flow modifications

venv is not the “official one true way,”
but one practical implementation prioritizing coexistence and isolation

🧭 Docker vs Nix / venv (Conceptual Comparison)

• Docker: close the environment
• Nix / venv: design the environment

This difference reflects the philosophical divide
between OpenLane1 and OpenLane2.

🧩 Use Cases Where OpenLane2 Excels

OpenLane2 shows its strengths in scenarios such as:

• SRAM / macro integration
• Parametric design
• Iterative design and regression runs
• Verification of the design flow itself

Conversely, for cases like:

• Beginners
• “I just want to generate a GDS once”

OpenLane1 is the better choice.

🚦 OpenLane2 Is Not a Replacement

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.

• OpenLane1: understanding and experience
• OpenLane2: design and operation

Using each where it fits best is the healthiest approach.

❓ The Next Question: PDK Compatibility

Once you start using OpenLane2,
you inevitably reach the next set of questions:

• Which PDKs are actually suitable for OpenLane?
• Why is SKY130 straightforward, while GF180 is more difficult?

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.

📝 Summary

• OpenLane2 is a foundation redesigned for designers
• Python-based because flow control is the priority
• Nix is officially recommended; Docker is also supported
• venv-based usage is one coexistence-oriented implementation
• It does not compete with OpenLane1

OpenLane2 is a tool for:

Moving from “running a flow”
to actively “operating and evolving” the design process