OpenROAD-flow-scripts drives an RTL to GDSII run from a Makefile

The scripts are the product, the tools are interchangeable

The repository description puts it plainly: OpenROAD-flow-scripts, usually shortened to ORFS, is a fully autonomous RTL to GDSII flow for architecture and design space exploration, early prediction of quality of results, and detailed physical design implementation. What it actually contains is a script layer, and the repository is written mostly in Tcl and Verilog with Python APIs alongside. Synthesis is done by Yosys, the signoff steps by KLayout, and the physical implementation stages by OpenROAD itself. None of those tools live here. The value is in the sequence and the hand-offs between them, which is exactly the part that a single vendor tool would hide. The README is explicit that the automation is not the only mode: ORFS also enables manual intervention for finer user control of individual flow stages through Tcl commands and Python APIs, so the Makefile is a starting point rather than a sealed box.

From floorplan to GDSII, stage by stage

The flow is laid out as a timeline in the README, and reading it tells you what a run actually does. Synthesis takes RTL, SDC constraints, .lib timing libraries and .lef abstracts and produces a netlist plus updated constraints, with Yosys as the tool. The floorplan stage initialises the die, places IOs at random as a first pass, does timing driven mixed size placement, places macros, inserts tapcells and wellties, and generates the power delivery network. Placement then runs global placement without the placed IOs, replaces the random IO placement with an optimised one, repeats global placement with the IOs fixed, resizes and buffers, and finishes with detailed placement. Clock tree synthesis follows with timing optimisation and filler cell insertion. Routing covers global then detailed routing, and the finishing stage adds metal fill, produces a signoff timing report, generates the GDSII with KLayout, and runs DRC and LVS checks through KLayout as well.

Docker, pre-built binaries or Bazel, and the choice is yours

The installation section says outright that there are multiple ways to install and develop OpenROAD and ORFS, and that the best option depends on your use case, experience level and preference. Three routes are offered. The README recommends Docker for new users, since the container image carries the ORFS binaries, the applications and all required dependencies, and that avoids most dependency and environment issues. Pre-built binaries are presented as an even simpler option on supported platforms, because they avoid building from source, and they cover OpenROAD, Yosys and KLayout together, with the binaries provided and supported by Precision Innovations. The third route is the Bazel based flow via the separate bazel-orfs repository, which resolves, versions and builds dependencies in a consistent environment and lets you adapt the flow in your own repository without manual installations, no Docker images and no sudo bash scripts. A local build from sources is documented separately, and the trade is that you own the dependency resolution yourself.

A Dockerfile that assembles the whole toolchain

The container image is the cleanest way to see what a run needs, because the Dockerfile at the root of the repository spells out the composition. It starts from a development base image, copies the Yosys install tree into the tools directory, copies the OpenROAD binary out of a builder image, and then copies the flow directory and the env script into the working directory. That last part is the bit worth noticing: the flow scripts and the environment setup travel with the binaries, so the container is not a loose collection of tools but a self-contained flow. The image also relaxes permissions recursively on the checkout so the mounted working directory does not fight the container user. Here is the composition as written:

# Target with dependencies and the binaries to run the complete flow
FROM openroad/flow-dev

WORKDIR /OpenROAD-flow-scripts

# synthesis tools binaries and plugins
COPY --from=openroad/yosys /install ./tools/install/yosys

# openroad binary

Because the build steps pull from several upstream images, the container path is reproducible in a way that a hand assembled tool directory rarely is, and it is the reason the README points new users at Docker first.

Running the flow from your own git repository without forking

The Makefile is the entry point, and one of the more useful properties of the project is that you do not have to fork it to use it. The README states that ORFS supports hosting projects in your own git repository without the need to fork ORFS. The invocation points make at a flow Makefile inside an existing OpenROAD-flow-scripts checkout, and passes a design configuration path through the DESIGN_CONFIG variable, so the design specific settings live in your tree and the flow scripts stay where they are. The documented form is:

    cd /home/me/myproject
    make --file=~/OpenROAD-flow-scripts/flow/Makefile DESIGN_CONFIG=somefolder/config.mk ...

This is the point where a design space exploration exercise becomes something you can script, because the design configuration is a file rather than an interactive session, and the same command can be re-run after an edit. The repository also ships a flow directory alongside docs, tools, docker, etc and a bazel directory, plus a Jenkinsfile, which points to continuous integration being a normal part of how the flow is exercised rather than an afterthought.

Where the guarantees stop, and why that matters

The README is unusually candid about what is not guaranteed, and the three statements sit together. Only the latest version of OpenROAD is guaranteed to work with the latest version of ORFS. Versions of OpenROAD, Yosys and KLayout provided by other third-party vendors are not guaranteed to work with ORFS. And a flow in which the scripts, the synthesis tool, the implementation tool and the signoff tool all have to agree is exactly the kind of flow where a version skew shows up as a strange failure deep in a long run rather than an error at startup. For an academic or exploratory run this is tolerable. For a design you intend to keep, pinning versions is the difference between a reproducible result and a lucky one. The repository layout also hints at how much of the surrounding work is automated: AGENTS.md and CLAUDE.md sit next to the build scripts, and there are tools for tclint and yamlfix configured, which suggests the flow is expected to be edited by people and agents and then checked.

BSD for the scripts, separate terms for everything they call

The licensing is layered, and the layering is the point. The OpenROAD-flow-scripts repository, covering the build and run scripts, has a BSD 3-Clause licence, and the file carrying it is named LICENSE_BUILD_RUN_SCRIPTS at the root of the repository. The flow then relies on several tools, platforms and designs that each carry their own licences, and the README points you at the licence inside the tools directory of the checkout for each of them, including the OpenROAD source tree. The repository description lists the license field as other with a custom licence that GitHub cannot classify, which is a reminder to read the file rather than trust a badge. Nothing here is legal advice, but the practical shape is clear enough: the scripts you wrote are yours under a permissive licence, while the tool binaries carry obligations that travel with whatever you distribute.

Editorial conclusion

OpenROAD-flow-scripts suits engineers who want an open source physical design flow they can run end to end and then take apart stage by stage, since every stage is reachable through Tcl commands and Python APIs rather than hidden behind the Makefile. It does not suit a team that needs a signed-off production tapeout flow, because the flow and its tools carry separate licences and only the scripts are under BSD 3-Clause. Before adopting, read the note in the README that only the latest OpenROAD version is guaranteed to work with the latest ORFS, decide between the Docker image, the pre-built binaries and the Bazel based approach, and pin your tool versions before the flow starts, since a mismatched Yosys, OpenROAD or KLayout build is not covered by any guarantee.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. The-OpenROAD-Project/OpenROAD-flow-scripts on GitHub