Skip to content

OpenLANE is an automated RTL to GDSII flow based on several components including OpenROAD, Yosys, Magic, Netgen, Fault and custom methodology scripts for design exploration and optimization.

Go to file

  ___   ____   ___  ____   _       ____  ____     ___
 /   \ |    \ /  _]|    \ | |     /    ||    \   /  _]
|     ||  o  )  [_ |  _  || |    |  o  ||  _  | /  [_
|  O  ||   _/    _]|  |  || |___ |     ||  |  ||    _]
|     ||  | |   [_ |  |  ||     ||  _  ||  |  ||   [_
 \___/ |__| |_____||__|__||_____||__|__||__|__||_____|

Table of contents

License Build Status


OpenLANE is an automated RTL to GDSII flow based on several components including OpenROAD, Yosys, Magic, Netgen, Fault, OpenPhySyn, SPEF-Extractor and custom methodology scripts for design exploration and optimization. The flow performs full ASIC implementation steps from RTL all the way down to GDSII - this capability will be released in the coming weeks with completed SoC design examples that have been sent to SkyWater for fabrication.

Join the community on slack!


  • Docker (ensure docker daemon is running) -- tested with version 19.03.12, but any recent version should suffice
  • Magic VLSI Layout Tool is needed to run open_pdks -- version >= 8.3.60

For more details about the docker container and its process, the following instructions walk you through the process of using docker containers to build the needed tools then integrate them into OpenLANE flow.

Quick Start:

You can start setting up the skywater-pdk and openlane by running:

    git clone --branch rc4
    cd openlane
    export PDK_ROOT=<absolute path to where skywater-pdk and open_pdks will reside>
    make test # This is to test that the flow and the pdk were properly installed

the Makefile should do the following when you run the above command:

  • Clone Skywater-pdk and the specified STD_CELL_LIBRARY and build it.
  • Clone open_pdks and set up the STD_CELL_LIBRARY for OpenLANE use.
  • Build the OpenLANE docker.
  • Test the whole setup with a complete run on a small design spm.

Note: the default STD_CELL_LIBRARY is sky130_fd_sc_hd. You can change that inside the Makefile.

This should produce a clean run for the spm. The final layout will be generated here: ./designs/spm/runs/openlane_test/results/magic/spm.gds.

To run the regression test, which tests the flow against all available designs under ./designs/ vs the the benchmark results, run the following command:

    make regression_test

Your results will be compared with: sky130_fd_sc_hd.

After running you'll find a directory added under ./regression_results/ it will contain all the reports needed for you to know whether you've been successful or not. Check this for more details.

Note: if runtime is -1, that means the design failed. Any reported statistics from any run after the failure of the design is reported as -1 as well.

DISCLAIMER: The following sections are to give you an understanding of what happens under the hood in the Makefile.

Setting up the PDK: skywater-pdk

  • Clone and build at least one skywater-pdk standard cell Library inside the pdks directory:

    • To setup one standard cell library only
        export PDK_ROOT=<absolute path to where skywater-pdk and open_pdks will reside>
        cd  $PDK_ROOT
        git clone
        cd skywater-pdk
        git checkout 5cd70ed19fee8ea37c4e8dbd5c5c3eaa9886dd23
        git submodule update --init libraries/sky130_fd_sc_hd/latest
        make sky130_fd_sc_hd
    • To setup other SCLs:
      • replace sky130_fd_sc_hd with any of the following list:
        • sky130_fd_sc_hs
        • sky130_fd_sc_ms
        • sky130_fd_sc_ls
        • sky130_fd_sc_hdll
  • Setup the configurations and tech files for Magic, Netgen, OpenLANE using open_pdks:

        cd $PDK_ROOT
        git clone
        cd open_pdks
        git checkout 48db3e1a428ae16f5d4c86e0b7679656cf8afe3d
        ./configure --with-sky130-source=$PDK_ROOT/skywater-pdk/libraries --with-sky130-local-path=$PDK_ROOT
    	cd sky130
    	make install-local

Note: You can use different directories for sky130-source and local-path. However, in the instructions we are using $PDK_ROOT to facilitate the installation process

WARNING: Please, don't move sk130A from the installed directory because the generated .mag files contain absolute paths. Moving it will result in producing an invalid GDS.

  • To set the STD_CELL_LIBRARY (the default value is set to sky130_fd_sc_hd)
    • Open configuration/general.tcl

    • set STD_CELL_LIBRARY to one of the following:

        - sky130_fd_sc_hs
        - sky130_fd_sc_ms
        - sky130_fd_sc_ls
        - sky130_fd_sc_hdll

Refer to this for more details on the structure.

Setting up OpenLANE

Building the OpenLANE Docker

Building the Docker Image Locally

To setup openlane you can build the docker container locally following these instructions:

    git clone --branch rc4
    cd openlane/docker_build
    make merge
    cd ..

Pulling an Auto-Built Docker Image from Dockerhub

Alternatively, you can use the auto-built openlane docker images available through dockerhub.

Note: Make sure you have an account on dockerhub to execute the following step.

    git clone --branch rc4
    cd openlane
    docker pull efabless/openlane:rc4

Running OpenLANE

Running the Locally Built Docker Image

Issue the following command to open the docker container from /path/to/openlane to ensure that the output files persist after exiting the container:

    docker run -it -v $(pwd):/openLANE_flow -v $PDK_ROOT:$PDK_ROOT -e PDK_ROOT=$PDK_ROOT -u $(id -u $USER):$(id -g $USER) openlane:rc4

Running the Pulled Auto-Built Docker Image

If you pulled the docker image from dockerhub instead of building it locally, then run the following command:

    export IMAGE_NAME=efabless/openlane:rc4
    docker run -it -v $(pwd):/openLANE_flow -v $PDK_ROOT:$PDK_ROOT -e PDK_ROOT=$PDK_ROOT -u $(id -u $USER):$(id -g $USER) $IMAGE_NAME

Note: this will mount the openlane directory inside the container.

Use the following example to check the overall setup:

./flow.tcl -design spm

To run OpenLANE on multiple designs at the same time, check this section.

Having trouble running the flow? check FAQs

Command line arguments

The following are arguments that can be passed to flow.tcl

Argument Description
-design <folder path>
Specifies the design folder. A design folder should contain a config.tcl defining the design parameters.
If the folder is not found, ./designs directory is searched
-config_file <file>
Specifies the design's configuration file for running the flow.
For example, to run the flow using /spm/config2.tcl
Use run ./flow.tcl -design /spm -config_file /spm/config2.tcl
By default config.tcl is used.
-config_tag <name>
Specifies the design's configuration file for running the flow.
For example, to run the flow using designs/spm/config2.tcl
Use run ./flow.tcl -design spm -config_tag config2.tcl
By default config.tcl is used.
-tag <name>
Specifies a name for a specific run. If the tag is not specified, a timestamp is generated for identification of that run.
Can Specify the configuration file name in case of using -init_design_config
-run_path <path>
Specifies a path to save the run in. By default the run is in design_path/, where the design path is the one passed to -design
A flag to save a runs results like .mag and .lef in the design's folder
-save_path <path>
Specifies a different path to save the design's result. This options is to be used with the -save flag
-src <verilog_source_file>
Sets the verilog source code file(s) in case of using `-init_design_config`.
The default is that the source code files are under design_path/src/, where the design path is the one passed to -design
Creates a tcl configuration file for a design. -tag <name> can be added to rename the config file to <name>.tcl
Flag to overwirte an existing run with the same tag
Flag to run openlane flow in interactive mode
-file <file_path>
Passes a script of interactive commands in interactive mode

Adding a design

To add a new design, follow the instructions provided here

This file also includes useful information about the design configuration files. It also includes useful utilities for exploring and updating design configurations for each (PDK,STD_CELL_LIBRARY) pair.

OpenLANE Architecture

OpenLANE Design Stages

OpenLANE flow consists of several stages. By default all flow steps are run in sequence. Each stage may consist of multiple sub-stages. OpenLANE can also be run interactively as shown here.

  1. Synthesis
    1. yosys - Performs RTL synthesis
    2. abc - Performs technology mapping
    3. OpenSTA - Pefroms static timing analysis on the resulting netlist to generate timing reports
  2. Floorplan and PDN
    1. init_fp - Defines the core area for the macro as well as the rows (used for placement) and the tracks (used for routing)
    2. ioplacer - Places the macro input and output ports
    3. pdn - Generates the power distribution network
    4. tapcell - Inserts welltap and decap cells in the floorplan
  3. Placement
    1. RePLace - Performs global placement
    2. Resizer - Performs optional optimizations on the design
    3. OpenPhySyn - Performs timing optimizations on the design
    4. OpenDP - Perfroms detailed placement to legalize the globally placed components
  4. CTS
    1. TritonCTS - Synthesizes the clock distribution network (the clock tree)
  5. Routing *
    1. FastRoute - Performs global routing to generate a guide file for the detailed router
    2. TritonRoute - Performs detailed routing
    3. SPEF-Extractor - Performs SPEF extraction
  6. GDSII Generation
    1. Magic - Streams out the final GDSII layout file from the routed def
  7. Checks
    1. Magic - Performs DRC Checks & Antenna Checks
    2. Netgen - Performs LVS Checks

OpenLANE integrated several key open source tools over the execution stages:

OpenLANE Output

All output run data is placed by default under ./designs/design_name/runs. Each flow cycle will output timestamp-marked foler containing the following file structure:

├── config.tcl
├── runs
│   ├── <tag>
│   │   ├── config.tcl
│   │   ├── logs
│   │   │   ├── cts
│   │   │   ├── floorplan
│   │   │   ├── magic
│   │   │   ├── placement
│   │   │   ├── routing
│   │   │   └── synthesis
│   │   ├── reports
│   │   │   ├── cts
│   │   │   ├── floorplan
│   │   │   ├── magic
│   │   │   ├── placement
│   │   │   ├── routing
│   │   │   └── synthesis
│   │   ├── results
│   │   │   ├── cts
│   │   │   ├── floorplan
│   │   │   ├── magic
│   │   │   ├── placement
│   │   │   ├── routing
│   │   │   └── synthesis
│   │   └── tmp
│   │       ├── cts
│   │       ├── floorplan
│   │       ├── magic
│   │       ├── placement
│   │       ├── routing
│   │       └── synthesis

To delete all generated runs under all designs:

  • inside the docker:
  • outside the docker:
        make clean_runs

Flow configuration

  1. PDK / technology specific
  2. Flow specific
  3. Design specific
  • A PDK should define at least one standard cell library(SCL) for the PDK. A common configuration file for all SCLs is located in:

    • Sometimes the PDK comes with several standard cell libraries. Each has an own configuration file that defines extra variables specific to the SCL. It may also override variables in the common PDK configuration file which is located in:

    • More on configuring a new PDK in this section

  • Flow specific variables are related to the flow and are initialized with default values in:

  • Finally, each design should have it's own configuration file with some required variables which are available in this list. A design configuration file may override any of the variables defined in PDK or flow configuration files. This is the global configurations for the design:

    • More on design configurations in here

A list of all available variables can be found here.

Regression And Design Configurations Exploration

As mentioned earlier, everytime a new design or a new (PDK,STD_CELL_LIBRARY) pair is added, or any update happens in the flow tools, a re-configuration for the designs is needed. The reconfiguration is methodical and so an exploration script was developed to aid the designer in reconfiguring his designs if needed. As explained here that each design has multiple configuration files for each (PDK,STD_CELL_LIBRARY) pair.


OpenLANE provides, a script that can do multiple runs in a parallel using different configurations. A run consists of a set of designs and a configuration file that contains the configuration values. It is useful to explore the design implementation using different configurations to figure out the best one(s).

Also, it can be used for testing the flow by running the flow against several designs using their best configurations. For example the following run: spm using its default configuration files config.tcl. :

python3 --designs spm xtea md5 aes256 --tag test --threads 3

For more information on how to run this script, refer to this file

For more information on design configurations, how to update them, and the need for an exploration for each design, refer to this file

You can’t perform that action at this time.