OpenROAD: the RTL-to-GDSII application you drive from Tcl

What OpenROAD replaces, and for whom

OpenROAD is a digital implementation application: you give it a synthesized netlist, libraries (LEF and Liberty), and constraints (SDC), and it produces a placed, clock-tree-synthesized, routed layout and finally GDSII. The README describes the flow as Autonomous, No-Human-In-Loop, with a 24 hour turnaround target from RTL to GDSII. That framing is aimed at design space exploration, where you want to sweep architecture choices and get early QoR predictions without a human babysitting each stage.

The audience is narrower than a general EDA tool. The README lists research and commercial consumers by name: OpenROAD-flow-scripts, OpenLane from Efabless, Silicon Compiler from Zero ASIC, Hammer from UC Berkeley, and OpenFASoC for mixed-signal. Each of those wraps the same underlying engines. If you are writing your own flow controller, OpenROAD is the layer you build on; if you just want a finished flow, you probably want ORFS instead. The README also states the flow has been used in over 600 silicon-ready tapeouts for technologies up to 12nm, which is the clearest statement of where the project claims production credibility.

The six stages and the database underneath them

The flow is a fixed pipeline: Synthesis, Floorplan, Placement, Clock Tree Synthesis, Routing, Finishing. Synthesis is done by Yosys and consumes RTL, SDC, .lib and .lef, emitting a netlist and an updated SDC. Floorplan covers initialization, IO placement, macro placement, tapcell and welltie insertion, and PDN generation. Placement runs global placement without placed IOs, then optimized IO placement, then global placement again with IOs fixed, followed by resizing, buffering and detailed placement. CTS performs timing optimization and filler insertion. Routing is split into global and detailed routing. Finishing adds metal fill, produces a signoff timing report, generates GDSII through KLayout, and runs DRC/LVS checks in KLayout.

What binds those stages is OpenDB, the database listed in the repository topics alongside def, lef and gdsii. The README states that the application enables flexible flow control through an API with bindings in Tcl and Python. That is the architectural decision worth noticing: the stages are not a monolithic binary with a fixed script, they are callable steps over a shared in-memory representation. It is why OpenLane, Hammer and Silicon Compiler can each impose a different flow shape on the same engine. The cost is that you inherit the database's model of the design, and anything the database does not represent is not something you can script around.

Building OpenROAD from the Dockerfile

The repository ships a Dockerfile that builds a dev image on ubuntu:24.04 and installs dependencies through etc/DependencyInstaller.sh. The build stage takes a numThreads argument, and a Dockerfile comment notes that release builds pass the published version. Because the dev image serves both build systems, it also installs the Bazel dependency set, including bazelisk and the libxml2 and X11/xcb runtime libraries. A Bazel build path exists alongside CMake (BUILD.bazel and MODULE.bazel are at the top level, and cmake/ and CMakeLists.txt support the other).

The dependency installer is invoked with several flag combinations in that file, and they are worth reading before you write your own image, because they decide what lands in the container:

COPY etc/DependencyInstaller.sh /tmp/.
RUN <<EOF
set -e
/tmp/DependencyInstaller.sh -ci -base
/tmp/DependencyInstaller.sh -bazel
/tmp/DependencyInstaller.sh -ci -common -save-deps-prefixes=/etc/openroad_deps_prefixes.txt $INSTALLER_ARGS
EOF

A later stage in the same file builds from source and is named builder, taking numThreads as a build argument. The Dockerfile is the only build recipe given in the repository root, so it is the path to follow if you want a reproducible environment.

For a working flow rather than a bare binary, the README points to OpenROAD-flow-scripts as the native, ready-to-use prototyping and tapeout flow, with its own documentation. What you should expect from a successful run is the stage sequence above, ending in a GDSII file plus a signoff timing report and KLayout DRC/LVS results. The README does not print a minimal Tcl snippet, so the entry point to verify first is which commands your build exposes and how the database is opened.

Where the autonomous flow stops being enough

The README is explicit that ORFS enables manual intervention for finer user control of individual flow stages, which is an admission that the no-human-in-loop default does not cover every design. The default IO placement is described as random during floorplan, with an optimized IO placement inserted later during placement. For a design with tight interface timing, that ordering means the first global placement runs against IO positions that are not yet the final ones, and the flow relies on the later pass to recover. Whether that recovery is sufficient is design-dependent, and the README does not offer guidance on when to intervene.

The larger boundary is technology. The 12nm figure in the README is a statement about tapeouts already completed, not a guarantee for your process. Advanced-node effects, custom cell libraries, and foundry-specific DRC decks are not addressed in the README. A second limitation is verification scope: the flow ends with KLayout DRC/LVS and a signoff timing report. If your signoff requirement is a specific commercial tool's results, OpenROAD's output is an input to that step, not a replacement for it.

Finally, the release history is thin. The most recent release listed is v0.9.0-beta from 2020-07-06. Development clearly continues (the last push was on 2026-09-23), but if your adoption process depends on tagged releases rather than tracking master, you should confirm how the project expects you to pin a version.

OpenROAD against a scripted commercial flow

The natural alternative is a commercial implementation suite driven by its own Tcl scripting layer. The difference is not mainly the algorithms; it is who owns the flow. In a commercial suite, the vendor supplies the flow, the signoff correlation, and the support channel, and you adapt your design to it. In OpenROAD, the flow is something you assemble. OpenLane, Hammer and Silicon Compiler each made a different choice about how to assemble it, which is the clearest evidence that no single arrangement is canonical.

A second comparison is against using Yosys plus a detailed router directly, skipping the unified application. That gives you control over each step but loses OpenDB as the shared representation, so every handoff between tools becomes a file format conversion. The DEF, LEF and GDSII topics in the repository reflect that OpenROAD's value is partly in keeping the design in one database across synthesis, placement, CTS and routing.

A third alternative is staying with OpenROAD-flow-scripts and never touching the application API. That is a legitimate choice, and for most users it is the right one. You give up the ability to restructure stages, and in exchange you get the flow the project actually tests.

Licence, build cost and what upgrades look like

OpenROAD is BSD-3-Clause. That is a permissive licence, so embedding it in a larger system or shipping a modified build does not carry the copyleft obligations of a GPL-style licence. It also means there is no reciprocity requirement back to the project. The repository carries an AUTHORS file and a CODE_OF_CONDUCT.md, but the README does not describe a contributor licence agreement, so if your legal team cares about that detail, read LICENSE and CONTRIBUTING.md directly rather than inferring from the licence identifier.

The practical upgrade cost is the build, not the licence. The Dockerfile shows a dependency installer with multiple modes, a Qt5 strip step that only runs when the base image is Ubuntu, and a Bazel dependency set installed even for non-Bazel builds. Two build systems plus a Nix flake (flake.nix, default.nix) means multiple supported paths that can drift. If you pin a container built from this Dockerfile, upgrades are a rebuild; if you build natively, you own the dependency versions.

There is also a Python packaging surface (pyproject.toml, python/), but the file shown only configures Black with third-party excluded. It does not tell you how the Python bindings are distributed, so verify that separately if Python is your intended interface.

Editorial conclusion

Adopt OpenROAD if you need a scriptable, BSD-3-Clause RTL-to-GDSII engine and can read Tcl, or if you are building a flow controller on top of the OpenDB database and the analysis engines. Do not adopt it if you expect a GUI-driven, vendor-supported signoff suite with a commercial support contract, or if your process is above the 12nm technologies the README cites for tapeouts. Before committing, verify the exact build path for your platform in the OpenROAD-flow-scripts documentation and confirm which of the two build systems (CMake or Bazel) your environment is expected to use.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. The-OpenROAD-Project/OpenROAD on GitHub