| commit | ec499c4ad04322d9bfaaa971d578cd4a6d5851b1 | [log] [tgz] |
|---|---|---|
| author | Kareem Farid <kareem.farid@efabless.com> | Thu Apr 09 15:04:09 2020 +0000 |
| committer | Kareem Farid <kareem.farid@efabless.com> | Thu Apr 09 15:04:09 2020 +0000 |
| tree | ec89ddca09db71bc9bb9cc7155326b95aaa85d34 | |
| parent | 47fbf425be860ef3d5714baecce910912472be15 [diff] |
fix padframe cfg
___ ____ ___ ____ _ ____ ____ ___ / \ | \ / _]| \ | | / || \ / _] | || o ) [_ | _ || | | o || _ | / [_ | O || _/ _]| | || |___ | || | || _] | || | | [_ | | || || _ || | || [_ \___/ |__| |_____||__|__||_____||__|__||__|__||_____| ver 0.981
OpenLane is an automated RTL to GDSII flow based on OpenRoad EDA tools configured for the SkyWater PDK. The flow performs ASIC implementation steps from RTL all the way down to GDSII.
NOTICE: This software contains confidential information from SkyWater Technology Foundry. This software is provided to partners of Efabless Corporation through license agreement with SkyWater Technology Foundry Inc. You must have an appropriate confidentiality and license aggrement with SkyWater Technology Foundry Inc in order to access and use this software.
First install git lfs follow [these instructions]. Which is being used by pdk submodule 20
Then clone the repo:
git clone https://vault.efabless.com/foss/openroad.git openlane
Then pull the pdk submodule (without it‘s git history avoiding it’s huge size):
cd openlane git submodule update --init
Before running the flow, you need to build tools used by the flow. OpenLane uses the following tools:
The following instructions walk you through the process of using docker containers to build the needed tools then integrate them into OpenLane flow.
After building the docker image, issue the following command to open the docker container:
docker run -it openlane:latest
The docker container will open in the directory of the openlane flow.
You can also issue the following command from the project root, to ensure that the output files persist after exiting the container:
docker run -itv $(pwd):/openLANE_flow openlane:latest
Note: this will mirror the openlane directory inside the container.
Then, you can test the flow using one of the provided designs (spm: Serial-Parallel Adder) by running:
./flow.tcl -design spm
To add a new design, the following command creates a configuration file for your design:
./flow.tcl -design <design_name> -init_design_config
This will create the following directory structure:
designs/<design_name> ├── config.tcl
In the configuration file, you should edit the required variables and the optional variables, if needed. Further information about the variables can be found here
It is recommended to place the design‘s verilog files in a src directory inside the design’s folder as following:
designs/<design_name> ├── config.tcl ├── src │ ├── design.v
Optionally, you can specify the configuration file name (without the extension) by using:
./flow.tcl -design <design_name> -init_design_config -tag <config_name>
After adding the design, you can specify the design name using a -design argument:
./flow.tcl -design <design_name>
Finally, you can specify the configuration file (belonging to that design) the flow should use:
./flow.tcl -design <design_name> -config <config_name>
The following are arguments that can be passed to flow.tcl
OpenLane flow consists of several stages. Each stage may consist of multiple sub-stages. OpenLane can run either interactively (the designer executes the flow steps one by one) or non-interactively (default; running all the flow steps one after another). The following diagram illustrates the flow steps:
yosys - Performs RTL synthesisabc - Performs technology mappingOpenSTA - Pefroms static timing analysis on the resulting netlist to generate timing reportsverilog2def - 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 portspdn - Generates the power distribution networktapcell - Inserts welltap and decap cells in the floorplanRePLace - Performs global placementOpenDP Perfroms detailed placement to legalize the globally placed componentsTritonCTS - Synthesizes the clock distribution network (the clock tree)FastRoute - Performs global routing to generate a guide file for the detailed routerTritonRoute - Performs detailed routingmagic - Streams out the final GDSII layout file from the routed def* addspacers is run just before routing to insert fill cells
After running a design, a directory called runs is created inside that design folder. Each run is placed under that directory. A run is either named after -tag or named with a timestamp of that run. A run folder contains:
logs - Runtime log of each tool. Can be useful in case of a crash.reports - Reports generated by some of the tools. (i.e. synthesis report, timing report, etc...)results - Final files created by completing a stage. Can either be .def or .v or .gds.tmp - Files created by substages.The resulting directory tree is as follows:
designs/spm ├── 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
OpenLane requires some environment variables to be defined. These variables are split into three main categories:
A PDK should define at least one variant for the PDK. A common configuration file for all PDK variants is located in:
./pdks/<pdk>/common_config.tcl
Sometimes the PDK comes with several Standard Cell Libraries or Metal Stacks. Each is considered as a PDK variant. A variant configuration file defines extra variables specific to the variant. It may also override variables in the common PDK configuration file which is located in:
./pdks/<pdk>/<variant>/config.tcl
Flow specific variables are related to the flow and are initialized with default values in:
./configuration/
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:
./designs/<design>/config.tcl
A list of all available variables can be found here.
You may run the flow interactively by using the -interactive option:
./flow.tcl -interactive
A tcl shell will be opened where you must first source the openlane package:
% package require openlane 0.9
Then, you should be able to run the following commands:
prep -design <design> -tag <tag> -config <config> -init_design_config -overwrite similar to the command line arguments, design is required and the rest is optionalrun_synthesisrun_floorplanrun_placementrun_ctsrun_routingrun_magicThe above commands can also be written in a file and passed to flow.tcl:
./flow.tcl -interactive -file <file>
Note 1: Currently, configuration variables have higher priority over the above commands so if RUN_MAGIC is 0, command run_magic will have no effect.
Note 2: Currently, all these commands must be run in sequence and none should be omitted.
OpenLane provides 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). For examples, check the Usage section.
Also, it can be used for testing the flow by running the flow against several designs using their best configurations. For example the following has two runs: spm and xtea using their default configuration files config.tcl. :
python3 run_designs.py --designs spm xtea des aes256 raven_soc --tag test --threads 3
The script can be used in two ways
Running one or more designs.
python3 run_designs.py --designs spm xtea PPU APU
An exploration run that generates configuration files of all possible combinations of the passed regression file and runs them on the provided designs.
python3 run_designs.py --designs spm xtea --regression ./scripts/config/regression.config
These parameters must be provided in the file passed to --regression. Any file can be used. The file used above is just an example
adjustment_factor=(0.1 0.15)
utilization=(40 50)
density=(0.4)
synth_strategy=(1 3)
pdn_v_pitch=("153.6")
pdn_h_pitch=("153.18")
aspect_ratio=(1)
max_fanout=(5)
extra="
set ::env(PDK_VARIANT) efs8hd
"
In addition, extra is appended to every configuration file generated. So it is used to add some configurations specific to this regression run.
Important Note: If you are going to launch two or more separate regression runs that include same design(s), make sure to set different tags for them using the --tag option.
designs/<design>/runs/config_<tag>_<number> for each run on a design, three files are produced:logs/<tag>_<timestamp>.log A log file that describes start and stopping time of a given run.logs/<tag>_<timestamp>.rpt A report file that provides a summary of each run. The summary contains some metrics and the configuration of that runlogs/<tag>_<timestamp>_best.rpt A report file that selects the best configuration per design based on number of violationsUsing openlane, you can produce a GDSII from a chip RTL.
For example, striVe:
The current methodology involves first hardenning the modules inside the chip as macros, then use these macros to generate the chip GDSII.
The following inputs are provided to produce striVe GDSII:
Given these inputs the following interactive script script. Mainly, it does the following steps:
chip_floorplan which first generates a floorplan using verilog2def followed by removing PINS section and cleaning NETS section in the generated def file