## File: README.md # OpenROAD [](https://jenkins.openroad.tools/job/OpenROAD-Public/job/master/) [](https://scan.coverity.com/projects/the-openroad-project-openroad) [](https://openroad.readthedocs.io/en/latest/?badge=latest) [](https://bestpractices.coreinfrastructure.org/en/projects/5370) ## About OpenROAD OpenROAD is the leading open-source, foundational application for semiconductor digital design. The OpenROAD flow delivers an Autonomous, No-Human-In-Loop (NHIL) flow, 24 hour turnaround from RTL-GDSII for rapid design exploration and physical design implementation. ``` /* Detailed source-code truncated for AI context efficiency. */ ``` ## OpenROAD Mission [OpenROAD](https://theopenroadproject.org/) eliminates the barriers of cost, schedule risk and uncertainty in hardware design to promote open access to rapid, low-cost IC design software and expertise and system innovation. The OpenROAD application enables flexible flow control through an API with bindings in Tcl and Python. OpenROAD is used in research and commercial applications such as, - [OpenROAD-flow-scripts](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts) from [OpenROAD](https://theopenroadproject.org/) - [OpenLane](https://github.com/The-OpenROAD-Project/OpenLane) from [Efabless](https://efabless.com/) - [Silicon Compiler](https://github.com/siliconcompiler/siliconcompiler) from [Zero ASIC](https://www.zeroasic.com/) - [Hammer](https://docs.hammer-eda.org/en/latest/Examples/openroad-nangate45.html) from [UC Berkeley](https://github.com/ucb-bar) - [OpenFASoC](https://github.com/idea-fasoc/OpenFASOC) from [IDEA-FASoC](https://github.com/idea-fasoc) for mixed-signal design flows OpenROAD fosters a vibrant ecosystem of users through active collaboration and partnership through software development and key alliances. Our growing user community includes hardware designers, software engineers, industry collaborators, VLSI enthusiasts, students and researchers. OpenROAD strongly advocates and enables IC design-based education and workforce development initiatives through training content and courses across several global universities, the Google-SkyWater [shuttles](https://platform.efabless.com/projects/public) also includes GlobalFoundries shuttles, design contests and IC design workshops. The OpenROAD flow has been successfully used to date in over 600 silicon-ready tapeouts for technologies up to 12nm. ## Getting Started with OpenROAD-flow-scripts OpenROAD provides [OpenROAD-flow-scripts](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts) as a native, ready-to-use prototyping and tapeout flow. However, it also enables the creation of any custom flow controllers based on the underlying tools, database and analysis engines. Please refer to the flow documentation [here](https://openroad-flow-scripts.readthedocs.io/en/latest/). OpenROAD-flow-scripts (ORFS) is a fully autonomous, RTL-GDSII flow for rapid architecture and design space exploration, early prediction of QoR and detailed physical design implementation. However, ORFS also enables manual intervention for finer user control of individual flow stages through Tcl commands and Python APIs. Figure below shows the main stages of the OpenROAD-flow-scripts: ```mermaid %%{init: { 'logLevel': 'debug', 'theme': 'dark' } }%% timeline title RTL-GDSII Using OpenROAD-flow-scripts Synthesis : Inputs [RTL, SDC, .lib, .lef] : Logic Synthesis (Yosys) : Output files [Netlist, SDC] Floorplan : Floorplan Initialization : IO placement (random) : Timing-driven mixed-size placement : Macro placement : Tapcell and welltie insertion : PDN generation Placement : Global placement without placed IOs : IO placement (optimized) : Global placement with placed IOs : Resizing and buffering : Detailed placement CTS : Clock Tree Synthesis : Timing optimization : Filler cell insertion Routing : Global Routing : Detailed Routing Finishing : Metal Fill insertion : Signoff timing report : Generate GDSII (KLayout) : DRC/LVS check (KLayout) ``` Here are the main steps for a physical design implementation using OpenROAD; - `Floorplanning` - Floorplan initialization - define the chip area, utilization - IO pin placement (for designs without pads) - Tap cell and well tie insertion - PDN- power distribution network creation - `Global Placement` - Macro placement (RAMs, embedded macros) - Standard cell placement - Automatic placement optimization and repair for max slew, max capacitance, and max fanout violations and long wires - `Detailed Placement` - Legalize placement - align to grid, adhere to design rules - Incremental timing analysis for early estimates - `Clock Tree Synthesis` - Insert buffers and resize for high fanout nets - `Optimize setup/hold timing` - `Global Routing` - Antenna repair - Create routing guides - `Detailed Routing` - Legalize routes, DRC-correct routing to meet timing, power constraints - `Chip Finishing` - Parasitic extraction using OpenRCX - Final timing verification - Final physical verification - Dummy metal fill for manufacturability - Use KLayout or Magic using generated GDS for DRC signoff ### GUI The OpenROAD GUI is a powerful visualization, analysis, and debugging tool with a customizable Tcl interface. The below figures show GUI views for various flow stages including floorplanning, placement congestion, CTS and post-routed design. #### Floorplan #### Automatic Hierarchical Macro Placement #### Placement Congestion Visualization #### CTS #### Routing ### PDK Support The OpenROAD application is PDK independent. However, it has been tested and validated with specific PDKs in the context of various flow controllers. OpenLane supports SkyWater 130nm and GlobalFoundries 180nm. OpenROAD-flow-scripts supports several public and private PDKs including: #### Open-Source PDKs - `GF180` - 180nm - `SKY130` - 130nm - `Nangate45` - 45nm - `ASAP7` - Predictive FinFET 7nm #### Proprietary PDKs These PDKS are supported in OpenROAD-flow-scripts only. They are used to test and calibrate OpenROAD against commercial platforms and ensure good QoR. The PDKs and platform-specific files for these kits cannot be provided due to NDA restrictions. However, if you are able to access these platforms independently, you can create the necessary platform-specific files yourself. - `GF55` - 55nm - `GF12` - 12nm - `Intel22` - 22nm - `Intel16` - 16nm - `TSMC65` - 65nm ## Tapeouts OpenROAD has been used for full physical implementation in over 600 tapeouts in SKY130 and GF180 through the Google-sponsored, Efabless [MPW shuttle](https://efabless.com/open_shuttle_program) and [ChipIgnite](https://efabless.com/) programs. ### OpenTitan SoC on GF12LP - Physical design and optimization using OpenROAD ### Continuous Tapeout Integration into CI The OpenROAD project actively adds successfully taped out MPW shuttle designs to the [CI regression testing](https://github.com/The-OpenROAD-Project/OpenLane-MPW-CI). Examples of designs include Open processor cores, RISC-V based SoCs, cryptocurrency miners, robotic app processors, amateur satellite radio transceivers, OpenPower-based Microwatt etc. ## Build OpenROAD To build OpenROAD tools locally on your machine, follow steps from [here](docs/user/Build.md). ### Third-party dependencies: submodules vs. Bazel BCR OpenROAD ships two build systems, and they source third-party code differently: - **CMake**: CMake has no central registry of versioned dependencies, so third-party sources are vendored as git submodules (see `.gitmodules` and the nested `.gitmodules` files under each submodule). Some of these submodules look like forks but are really just pinned upstream trees; they exist so CMake has a directory to point at. These are upstream mirrors — kept as submodules because that is what CMake can consume. - **Bazel**: prefer the idiomatic options, in order: 1. A module from the [Bazel Central Registry](https://registry.bazel.build/) (`bazel_dep` in `MODULE.bazel`). This is the default — pinned, mirrored, reproducible, and no submodule needed. 2. If the dependency is not on BCR, fetch the upstream repository directly with `http_archive` (preferred) or a module extension. For modules that exist on BCR but need a different revision, `git_override` (pinned by commit) or `archive_override` (pinned by URL + SHA256) can be used. Bring a BUILD overlay only when upstream does not ship one. 3. A real fork (with OpenROAD-specific patches) stays as a git submodule because that is also what CMake needs; Bazel then references it via its local path. The rule of thumb: if Bazel can get it from BCR or directly from the upstream repo, do not add a submodule just for Bazel. Submodules are the CMake-side compromise, not the source of truth for Bazel builds. ## Regression Tests There are a set of executable regression test scripts in `./test/`. ``` shell # run tests for all tools ./test/regression # run all flow tests ./test/regression flow # run tests ./test/regression # run all -specific unit tests cd src/ ./test/regression # run only for cd src/ ./test/regression ``` The flow tests check results such as worst slack against reference values. Use `report_flow_metrics [test]...` to see all of the metrics. ``` text % report_flow_metrics gcd_nangate45 insts area util slack_min slack_max tns_max clk_skew max_slew max_cap max_fanout DPL ANT drv gcd_nangate45 368 564 8.8 0.112 -0.015 -0.1 0.004 0 0 0 0 0 0 ``` To update a failing regression, follow the instructions below: ```tcl # update log files (i.e. *ok) save_ok # update "*.metrics" for tests that use flow test save_flow_metrics # update "*.metrics_limits" files save_flow_metrics_limits ``` ## Run ``` text openroad [-help] [-version] [-no_init] [-exit] [-gui] [-threads count|max] [-log file_name] [-db file_name] cmd_file -help show help and exit -version show version and exit -no_init do not read .openroad init file -threads count|max use count threads -no_splash do not show the license splash at startup -exit exit after reading cmd_file -gui start in gui mode -python start with python interpreter [limited to db operations] -log write a log in -db open a .odb database at startup cmd_file source cmd_file ``` OpenROAD sources the Tcl command file `~/.openroad` unless the command line option `-no_init` is specified. OpenROAD then sources the command file `cmd_file` if it is specified on the command line. Unless the `-exit` command line flag is specified, it enters an interactive Tcl command interpreter. A list of the available tools/modules included in the OpenROAD app and their descriptions are available [here](docs/contrib/Logger.md#openroad-tool-list). ## Git Quickstart OpenROAD uses Git for version control and contributions. Get familiarised with a quickstart tutorial to contribution [here](docs/contrib/GitGuide.md). ## Understanding Warning and Error Messages Seeing OpenROAD warnings or errors you do not understand? We have compiled a table of all messages and you may potentially find your answer [here](https://openroad.readthedocs.io/en/latest/user/MessagesFinal.html). ## License BSD 3-Clause License. See [LICENSE](LICENSE) file. --- ## File: docs/index.md # Welcome to OpenROAD's documentation! The OpenROAD ("Foundations and Realization of Open, Accessible Design") project was launched in June 2018 within the DARPA IDEA program. OpenROAD aims to bring down the barriers of cost, expertise and unpredictability that currently block designers' access to hardware implementation in advanced technologies. The project team (Qualcomm, Arm and multiple universities and partners, led by UC San Diego) is developing a fully autonomous, open-source tool chain for digital SoC layout generation, focusing on the RTL-to-GDSII phase of system-on-chip design. Thus, OpenROAD holistically attacks the multiple facets of today's design cost crisis: engineering resources, design tool licenses, project schedule, and risk. The IDEA program targets no-human-in-loop (NHIL) design, with 24-hour turnaround time and zero loss of power-performance-area (PPA) design quality. The NHIL target requires tools to adapt and auto-tune successfully to flow completion, without (or, with minimal) human intervention. Machine intelligence augments human expertise through efficient modeling and prediction of flow and optimization outcomes throughout the synthesis, placement and routing process. This is complemented by development of metrics and machine learning infrastructure. The 24-hour runtime target implies that problems must be strategically decomposed throughout the design process, with clustered and partitioned subproblems being solved and recomposed through intelligent distribution and management of computational resources. This ensures that the NHIL design optimization is performed within its available `[threads * hours]` "box" of resources. Decomposition that enables parallel and distributed search over cloud resources incurs a quality-of-results loss, but this is subsequently recovered through improved flow predictability and enhanced optimization. For a technical description of the OpenROAD flow, please refer to our DAC-2019 paper: [Toward an Open-Source Digital Flow: First Learnings from the OpenROAD Project](https://vlsicad.ucsd.edu/Publications/Conferences/371/c371.pdf). The paper is also available from [ACM Digital Library](https://dl.acm.org/doi/10.1145/3316781.3326334). Other publications and presentations are linked [here](https://theopenroadproject.org/publications/). ## Documentation The OpenROAD Project has two releases: - Application ([github](https://github.com/The-OpenROAD-Project/OpenROAD)) ([docs](main/README.md)): The application is a standalone binary for digital place and route that can be used by any other RTL-GDSII flow controller. - Flow ([github](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts)) ([docs](https://openroad-flow-scripts.readthedocs.io/en/latest/)): This is the native OpenROAD flow that consists of a set of integrated scripts for an autonomous RTL-GDSII flow using OpenROAD and other open-source tools. ## Supported Operating Systems Note that depending on the installation method, we have varying levels of support for various operating systems. Legend: - `Y` for supported. - `-` for unsupported. | Operating System | Local Installation | Prebuilt Binaries | Docker Installation | Windows Subsystem for Linux | | --- | --- | --- | --- | --- | | Debian 12 | `Y` | `Y` | `Y` | `-` | | Debian 13 | `Y` | `Y` | `Y` | `-` | | Ubuntu 22.04 | `Y` | `Y` | `Y` | `-` | | Ubuntu 24.04 | `Y` | `Y` | `Y` | `-` | | Ubuntu 26.04 | `Y` | `Y` | `Y` | `-` | | RHEL 8/9 | `Y` | `-` | `Y` | `-` | | Rocky 8 | `Y` | `-` | `Y` | `-` | | Rocky 9 | `Y` | `-` | `Y` | `-` | | macOS | `Y` | `-` | `Y` | `-` | | Windows 10 and above | `-` | `-` | `Y` | `Y` | ## Code of conduct Please read our code of conduct [here](main/CODE_OF_CONDUCT.md). ## How to contribute If you are willing to **contribute**, see the [Getting Involved](contrib/GettingInvolved.md) section. If you are a **developer** with EDA background, learn more about how you can use OpenROAD as the infrastructure for your tools in the [Developer Guide](contrib/DeveloperGuide.md) section. OpenROAD uses Git for version control and contributions. Get familiarised with a quickstart tutorial to contribution [here](contrib/GitGuide.md). ## How to get in touch We maintain the following channels for communication: - Project homepage and news: - Twitter: - Issues and bugs: - OpenROAD: - Discussions: - OpenROAD: - Inquiries: openroad@ucsd.edu See also our [FAQs](user/FAQS.md). ## Site Map ```{tableofcontents} ``` --- ## File: docs/README.md # OpenROAD Documentation This `docs/` hierarchy houses code and raw files to build the on-line documentation (using Sphinx) and manual pages using (using Pandoc) This on-line documentation is available at [https://openroad.readthedocs.io/en/latest/](https://openroad.readthedocs.io/en/latest/). ### Requires: - Python 3.x - Pip - `virtualenv` - `doxygen` ## Prerequisites - To install pandoc, refer to this [link](https://github.com/jgm/pandoc/blob/main/INSTALL.md). `apt-get` *should* just work for Ubuntu. - To install sphinx requirements, **create a virtual environment (e.g. conda/virtualenv)** and then run `pip install -r requirements.txt`. You may install Doxygen from this [link](https://www.doxygen.nl/download.html). Most methods of installation are fine, just ensure that `doxygen` is in $PATH. This is needed for Doxygen compilation. To install Python packages: ``` shell virtualenv .venv source .venv/bin/activate pip install -r requirements.txt ``` ### Build instructions for Pandoc manpages The `-j16` command is optional for speeding up the manpage compilation process by using multiple jobs based on the number of cores in your system. ``` shell make clean # Note this step is important as it regenerates the documentation using latest sources. make preprocess && make all -j16 ``` #### To view manpages You will be prompted to enter the RELATIVE path to cat folders which is optional. ```tcl man openroad ``` ### Build instructions for Sphinx docs #### HTML docs ``` shell make html ``` #### Check for broken links ``` shell make checklinks ```