___ ____ ___ ____ _ ____ ____ ___ / \ | \ / _]| \ | | / || \ / _] | || o ) [_ | _ || | | o || _ | / [_ | O || _/ _]| | || |___ | || | || _] | || | | [_ | | || || _ || | || [_ \___/ |__| |_____||__|__||_____||__|__||__|__||_____|
Table of contents¶
OpenLANE is an automated RTL to GDSII flow based on several components including OpenROAD, Yosys, Magic, Netgen, Fault, OpenPhySyn, CVC, 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
You can start setting up the skywater-pdk and openlane by running:
git clone https://github.com/efabless/openlane.git --branch rc7 cd openlane/ export PDK_ROOT=<absolute path to where skywater-pdk and open_pdks will reside> make openlane make pdk make test # This is to test that the flow and the pdk were properly installed
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:
Your results will be compared with: sky130_fd_sc_hd.
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.
The Makefile should do the following when you run the above command:
Clone Skywater-pdk and the specified STD_CELL_LIBRARY, SPECIAL_VOLTAGE_LIBRARY, and IO_LIBRARY and build it.
Clone open_pdks and set up the pdk for OpenLANE use.
Build the OpenLANE docker.
Test the whole setup with a complete run on a small design
You can use dockerhub instead of building the docker locally. Check this section for more details.
the default STD_CELL_LIBRARY is sky130_fd_sc_hd. You can change that by running:
export STD_CELL_LIBRARY=<Library name, i.e. sky130_fd_sc_ls>
Other options are:
You can install the full pdk by running
make full-pdkinstead of
You can install the pdk manually -outside of the Makefile- by following the instructions provided here.
Refer to this for more details on the structure.
For curious users: 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. You Don’t Need To Re-Build The Tools.
If you already have the repo locally, then no need to re-clone it. You can directly run the following:
cd openlane/ git checkout master git pull git checkout rc7 export PDK_ROOT=<absolute path to where skywater-pdk and open_pdks will reside> make openlane make pdk make test # This is to test that the flow and the pdk were properly installed
This should install the latest openlane docker, and re-install the pdk for the latest used version. If you want to only update the openlane docker check this section after updating the repo.
Setting up OpenLANE¶
Building the OpenLANE Docker¶
DISCLAIMER: This sub-section is to give you an understanding of what happens under the hood in the Makefile. You don’t need to run the instructions here, if you already ran
Building the Docker Image Locally¶
To setup openlane you can build the docker container locally following these instructions:
git clone https://github.com/efabless/openlane.git --branch rc7 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: You may need to have an account on dockerhub to execute the following step.
git clone https://github.com/efabless/openlane.git --branch rc7 docker pull efabless/openlane:rc7
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:rc7
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:rc7 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
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
Specifies the design's configuration file for running the flow.
For example, to run the flow using
Specifies the design's configuration file for running the flow.
For example, to run the flow using
Can Specify the configuration file name in case of using
||A flag to save a runs results like .mag and .lef in the design's folder|
Specifies a different path to save the design's result. This options is to be used with the
Sets the verilog source code file(s) in case of using `-init_design_config`.
The default is that the source code files are under
Creates a tcl configuration file for a design.
|Flag to overwirte an existing run with the same tag|
|Flag to run openlane flow in interactive mode|
|Passes a script of interactive commands in interactive mode|
|If enabled, synthesis exploration will be run (only synthesis exploration), which will try out the available synthesis strategies against the input design. The output will be the four possible gate level netlists under <run_path/results/synthesis> and a summary report under reports that compares the 4 outputs.|
|If enabled, only LVS will be run on the design. in which case the user must also pass: -design DESIGN_DIR -gds DESIGN_GDS -net DESIGN_NETLIST.|
|If enabled, only DRC will be run on the design. in which case the user must also pass: -design DESIGN_DIR -gds DESIGN_GDS -report OUTPUT_REPORT_PATH -magicrc MAGICRC.|
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.
yosys- Performs RTL synthesis
abc- Performs technology mapping
OpenSTA- Pefroms static timing analysis on the resulting netlist to generate timing reports
Floorplan and PDN
init_fp- Defines the core area for the macro as well as the rows (used for placement) and the tracks (used for routing)
ioplacer- Places the macro input and output ports
pdn- Generates the power distribution network
tapcell- Inserts welltap and decap cells in the floorplan
RePLace- Performs global placement
Resizer- Performs optional optimizations on the design
OpenPhySyn- Performs timing optimizations on the design
OpenDP- Perfroms detailed placement to legalize the globally placed components
TritonCTS- Synthesizes the clock distribution network (the clock tree)
FastRoute- Performs global routing to generate a guide file for the detailed router
TritonRoute- Performs detailed routing
SPEF-Extractor- Performs SPEF extraction
Magic- Streams out the final GDSII layout file from the routed def
Magic- Performs DRC Checks & Antenna Checks
Netgen- Performs LVS Checks
CVC- Performs Circuit Validity Checks
OpenLANE integrated several key open source tools over the execution stages:
RTL Synthesis, Technology Mapping, and Formal Verification : yosys + abc
Static Timing Analysis: OpenSTA
Clock Tree Synthesis: TritonCTS
Fill Insertion: OpenDP/filler_placement
SPEF Extraction: SPEF-Extractor
GDSII Streaming out: Magic
DRC Checks: Magic
LVS check: Netgen
Antenna Checks: Magic
Circuit Validity Checker: CVC
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:
designs/<design_name> ├── config.tcl ├── runs │ ├── <tag> │ │ ├── config.tcl │ │ ├── logs │ │ │ ├── cts │ │ │ ├── cvc │ │ │ ├── floorplan │ │ │ ├── magic │ │ │ ├── placement │ │ │ ├── routing │ │ │ └── synthesis │ │ ├── reports │ │ │ ├── cts │ │ │ ├── cvc │ │ │ ├── floorplan │ │ │ ├── magic │ │ │ ├── placement │ │ │ ├── routing │ │ │ └── synthesis │ │ ├── results │ │ │ ├── cts │ │ │ ├── cvc │ │ │ ├── floorplan │ │ │ ├── magic │ │ │ ├── placement │ │ │ ├── routing │ │ │ └── synthesis │ │ └── tmp │ │ ├── cts │ │ ├── cvc │ │ ├── floorplan │ │ ├── magic │ │ ├── placement │ │ ├── routing │ │ └── synthesis
To delete all generated runs under all designs:
inside the docker:
outside the docker:
PDK / technology 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.
run_designs.py, 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
python3 run_designs.py --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
The first step of chip integration is hardening the macros. To learn more about this check this file.
Using openlane, you can produce a GDSII from a chip RTL. This is done by applying a certain methodology that we follow using our custom scripts and the integrated tools.
To learn more about Chip Integration. Check this file
Commands and Configurations¶
The full documentation of OpenLANE run configurations could be found here.