`. While TensorBoard is running, you can open the webpage `http://localhost:6006/` to see the GUI.
We show three different views possible at the end, namely: `Table View`, `Scatter Plot Matrix View` and `Parallel Coordinate View`.
Table View
Scatter Plot Matrix View
Parallel Coordinate View (best run is in green)
## Testing framework
Assuming the virtual environment is setup at `./tools/AutoTuner/autotuner_env`:
```default
./tools/AutoTuner/setup.sh
python3 ./tools/AutoTuner/test/smoke_test_sweep.py
python3 ./tools/AutoTuner/test/smoke_test_tune.py
python3 ./tools/AutoTuner/test/smoke_test_sample_iteration.py
```
## Citation
Please cite the following paper.
* J. Jung, A. B. Kahng, S. Kim and R. Varadarajan, “METRICS2.1 and Flow Tuning in the IEEE CEDA Robust Design Flow and OpenROAD”, [(.pdf)](https://vlsicad.ucsd.edu/Publications/Conferences/388/c388.pdf), [(.pptx)](https://vlsicad.ucsd.edu/Publications/Conferences/388/c388.pptx), [(.mp4)](https://vlsicad.ucsd.edu/Publications/Conferences/388/c388.mp4), Proc. ACM/IEEE International Conference on Computer-Aided Design, 2021.
## Acknowledgments
AutoTuner has been developed by UCSD with the OpenROAD Project.
# Jenkins.html.md
# Jenkins Continuous Integration
The Jenkins website is at [https://jenkins.openroad.tools/](https://jenkins.openroad.tools/).
For an in-depth tutorial on how to access the CI metrics, please see
the [link](https://docs.google.com/presentation/d/1kWHLjUBFcd0stnDaPNi_pt9WFrrsR7tQ95BGhT1yOvw/)
#### NOTE
This document is not static is constantly being updated due to changes
in the functionality of Jenkins.
# LargeDesigns.html.md
# Tips on building large design
Large designs can quickly result in unmanageable turnaround times for tweaking and fixing if the design contains behavioral memory models, because these memories are by default translated to flip flops.
ORFS has a `SYNTH_MEMORY_MAX_BITS` that limits the size of inferred memories that are translated to flip flops to avoid doomed synthesis runs that will “running forever”, instead ORFS will error out early, normally within minutes.
Behavioral models of memories are used in simulation and FPGA tools oftentimes automatically combine hard memory macros with some extra logic to match the behavioral model. OpenROAD does not do such automatic memory inference and matching against real memories or fakemem.
## Doing a screening build
Before deciding how to set up a flow, it is useful to do a “screening build”. All we’re intersted in here is to know which modules we have and their relative sizes. This can help us identify memories that have not been successfully inferred by Yosys, which will manifest itself as very long synthesis times and appear in the OpenROAD hierarchical view with a large number of instances.
The [minimal build configuration]()
can be useful to do a screening build.
Options useful for a screening build are, check out [config.mk]():
- `SYNTH_HIERARCHICAL=1` and `SYNTH_MINIMUM_KEEP_SIZE=0`, to see all modules in the hierarchical OpenROAD view
- `SYNTH_MEMORY_MAX_BITS=1024`, set a low threshold initially to get an error with list of memories in the system that will need to be dealt with in some way
- `SYNTH_MOCK_LARGE_MEMORIES=1` enabled after first seeing the error report with memories. This sets the number of rows in memories larger than `SYNTH_MEMORY_MAX_BITS` to 1, so that synthesis will complete.
## Next steps on memories
- If you’re taping out, write some wrapper Verilog for real memories.
- fakemem can be a good option if available for your PDK. fakemem also needs manually written Verilog wrappers, just like real memories.
- For architectural exploration, `SYNTH_MOCK_LARGE_MEMORIES=1` could give you adequate timing accuracy and is convenient.
# Manpage.html.md
# Utilities
The utility module contains the `man` command.
## Commands
#### NOTE
- Parameters in square brackets `[-param param]` are optional.
- Parameters without square brackets `-param2 param2` are required.
### Prometheus Metrics
OpenROAD includes a metrics endpoint server that can track internal tool metrics over time.
To use this feature you need to do the following start the prometheus and grafana collectors
[Detailed instructions]():
```shell
$ cd etc/monitoring
$ docker compose up -d
```
This will start a grafana endpoint ready to collect from the OpenROAD application you would
like to track. By default it’s looking for an http server running on port 8080 on your localhost.
To start the metrics endpoint in OpenROAD, run:
```tcl
utl::startPrometheusEndpoint 8080
```
This is all configurable in the docker compose file, and you should be able to access grafana by going to
http://localhost:3000 username: admin, password: grafana. Go to the dashboard tab and click service,
then OpenROAD to see the pre-made dashboard.
## Man installation
The `man` command can be installed optionally as part of the OpenROAD
binary. For more instructions, please refer to [here]().
### Man
The `man` command in OpenROAD is similar in functionality to Unix
(and Unix-like operating systems such as Linux) . It is used to
display the manual pages for various applications, tools and error
messages. These manual pages provide detailed information about how
to use a particular command or function, along with its syntax and options.
This can be used for a range of commands in different levels as follows:
- Level 1: Top-level openroad command (e.g. `man openroad`)
- Level 2: Individual module commands (e.g. `man clock_tree_synthesis`)
- Level 3: Info, error, warning messages (e.g. `man CTS-0001`)
```tcl
man
name
[-manpath manpath]
[-no_pager]
```
#### Options
| Switch Name | Description |
|---------------|--------------------------------------------------------------------------------------------------------------------------------------|
| `name` | Name of the command/message to query. |
| `-manpath` | Include optional path to man pages (e.g. ~/OpenROAD/docs/cat). |
| `-no_pager` | This flag determines whether you wish to see all of the man output at once. Default value is `False`, which shows a buffered output. |
## Example scripts
You may run various commands or message IDs for man pages.
```default
man openroad
man clock_tree_synthesis
man CTS-0005
```
### tee
Redirect a commands output to a file and standard out.
```tcl
tee (-file filename | -variable name)
[-append]
[-quiet]
command
```
#### Options
| Switch Name | Description |
|------------------|-------------------------------------|
| `-file filename` | File to redirect output into. |
| `-variable name` | Direct output into a variable. |
| `-append` | Append to file. |
| `-quiet` | Do not send output to standard out. |
| `command` | Command to execute. |
## Example scripts
```default
tee -file output.rpt { report_design_area }
tee -quiet -file output.rpt { report_floating_nets }
```
## Regression tests
There are a set of regression tests in `./test`. For more information, refer to this [section]().
For information regarding the Man page test framework, refer to this
[link]().
You should also be aware of the [README]() and [Tcl]() format enforced to ensure
accurate parsing of man pages.
Simply run the following script:
```shell
./test/regression
```
## Limitations
## FAQs
Check out
[GitHub discussion](https://github.com/The-OpenROAD-Project/OpenROAD/discussions/categories/q-a?discussions_q=category%3AQ%26A+utl) about this tool.
## References
## Authors
MAN command is written by Jack Luar with guidance from members of the OpenROAD team,
including: Cho Moon, Matt Liberty.
## License
BSD 3-Clause License. See [LICENSE]() file.
# Metrics.html.md
# Metrics
The [OpenROAD-flow-scripts](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts)
repository contains source files (e.g., LEF/DEF, Verilog, SDC, Liberty,
RC extraction) and configuration files (e.g. `config.mk`) that enable the user to run
a small set of example designs through our complete RTL-to-GDS flow.
To keep track of the quality of the results, we maintain inside each
design folder two files:
1. `metadata-base-ok.json` which contains all the relevant
information extracted from the “golden” execution of the flow (i.e.,
last known good result).
2. `rules.json` which holds a set of rules that we use to
evaluate new executions when a change is made.
## Checking against golden
The evaluation checks for key metrics (e.g., worst slack, number of
DRCs) to ensure that changes do not degrade too much with respect to the
“golden” values.
After you make a significant change, e.g., fixing a bug in a piece of
code, or changing some configuration variable
(`PLACE_DENSITY`), you should review the results and compare
them with the “golden”. To perform the check, you will need to run the
following command:
```shell
cd OpenROAD-flow-scripts/flow
# the clean_metadata is only required if you need to re-run
make [clean_metadata] metadata
```
If the command above yields any error message, please review to
make sure the change in metrics is expected and justifiable. If so,
proceed to the next section to update the “golden” reference.
## Update process
Update of the reference files is mandatory if any metrics became worse
than the values limited by the `rules.json` (see previous
section on how to perform the check). Also, it is a good idea to update
the “golden” files if your changes have improved a metric, to ensure that
the improvement will not be lost in the future.
To update all the reference files:
```shell
cd OpenROAD-flow-scripts/flow
make update_ok
```
In case you have a special reason to only update one of the files, you
can do so with the following commands:
```shell
# update metadata-base-ok.json file for the design
make update_metadata
# update rules.json file for the design
# this will use the current (+ a padding) metadata-base-ok.json
# the padding ensures that small changes do not break the flow
make update_rules
```
# Notebooks.html.md
# Colab Quickstart
Notebook-based packaging offers three main benefits:
1. Colab is completely free to use and can be accessed from any web browser.
2. Colab notebooks can be easily shared with others, making it a great
tool for teams to collaborate and manage OpenROAD design runs.
3. The notebook can easily be modified to be used for on-premise servers or
notebook-based cloud providers such as LambdaLabs/Paperspace.
We provide two notebooks for a quickstart to OpenROAD-flow-scripts functionality
as follows:
## OpenROAD-flow-scripts Automated RTL-GDSII Flow
The notebook for the automated flow for `gcd` design in `nangate45` technology node can be found [here](https://colab.research.google.com/drive/1bfcvqOnbw8q7FmSONLw8q7-yBVvKsQot).
## AutoTuner Flow
The notebook for the OpenROAD-flow-scripts AutoTuner flow for `gcd` design in `sky130hd` technology node can be found [here](https://colab.research.google.com/drive/1wye0osn34YVWPvTrfBTftjOfGOtF3ABe).
# PlatformBringUp.html.md
# Guide to Integrate a New Platform into the OpenROAD Flow
## Overview
This document is a guide for foundry and third party IP providers to
easily integrate and test a new technology in to the OpenROAD RTL to GDS
flow. OpenROAD allows you to integrate any PDK (Process Design Kit) for any
feature size and implement a fully open-sourced RTL-GDSII flow (synthesizable
Verilog to merged GDSII). The OpenROAD flow has been validated for feature
sizes down to 7nm and used to design and tapeout over 600 ASIC and SoCs
to date.
## Prerequisites
To build and add a new platform for OpenROAD, key technology and library
components must be provided based on the technology node. These are generally
available as part of the standard design kit provided by a foundry or a
third-party IP provider.
They include :
* A standard cell library
* GDS files of all standard cells in the library (or a way to generate
them from the layout files, e.g., Magic VLSI layout tool).
* A technology LEF file of the PDK being used that includes all relevant
information regarding metal layers, vias, and spacing requirements.
* See `flow/platforms/nangate45/lef/NangateOpenCellLibrary.tech.lef`
as an example tech LEF file.
* A macro LEF file of the standard cell kit that includes MACRO definitions
of every cell, pin designations (input/output/inout).
* See `flow/platforms/nangate45/lef/NangateOpenCellLibrary.macro.lef`
as an example macro LEF file.
* A Liberty file of the standard cell library with PVT characterization,
input and output characteristics, timing and power definitions for
each cell.
* See `flow/platforms/nangate45/lib/NangateOpenCellLibrary_typical.lib`
as an example liberty file.
* For KLayout: A mapping from LEF/DEF to GDS `layers:datatypes`
Adding a new platform additionally requires the following:
* A validated installation of the OpenROAD flow scripts is available. See
instructions here.
* A general knowledge of VLSI design and RTL to GDS flows. OpenROAD
implements a fully-automated RTL-GDSII but it requires familiarity with
the OpenROAD flow scripts to debug problems.
## Adding a New Platform to OpenROAD
### Setup
This section describes the necessary files and directories needed to build
the platform. All files and directories made/edited are independent of
each other unless otherwise stated.
### Makefile
Make the following edits to the Makefile (located in `flow/Makefile`)
so that OpenROAD can run the flow on a design using the new platform.
At the beginning of the Makefile, there is a block of `DESIGN_CONFIG`
variables that are commented out. These variables tell OpenROAD which
design to run and on what platform. `DESIGN_CONFIG` specifically points
to a `config.mk` file located in the designs directory for the respective
platform. It is not required to add a `DESIGN_CONFIG` variable for a design
in the respective platform directly into the Makefile. It is merely a
convenience to add a `DESIGN_CONFIG` variable in the `Makefile` and can
instead be set when invoking make. OpenROAD has multiple Verilog designs
already made which can be used with any platform (see `flow/designs/src`
for a list of usable designs). For example, a `DESIGN_CONFIG` variable
using the `gcd` design on a new platform would look as follows:
```Makefile
DESIGN_CONFIG=./designs/MyNewPlatform/gcd/config.mk
```
The `config.mk` file will be generated later in the [Design
Directory](#content-design-directory) section of this document.
### Platform Directory
Create a directory for the new technology inside `flow/platforms` to contain
the necessary files for the OpenROAD flow.
```shell
mkdir flow/platforms/MyNewPlatform
```
### Design Directory
The design directory contains the configuration files for all the designs of
a specific platform. Create a directory for the new platform in flow/designs
to contain the relevant files and directories for all the designs for the
flow in that specific platform. Each design requires its own `config.mk`
and `constraint.sdc` files.
### Platform Configuration
This section describes the necessary files in the platform directory needed
for the OpenROAD flow. Specifically the `config.mk` file in the platform
directory has all of the configuration variables that the flow uses. Refer
to the OpenROAD-flow-scripts documentation for a full list of configuration
variables that can be set.
Refer to the [Flow variables](../user/FlowVariables.md) document for details on how to use
environment variables in OpenROAD-flow-scripts to configure platform and design specific parameters.
For an example of a platform `config.mk` file, refer to
`flow/platforms/sky130hd/config.mk.`
### Design Configuration
This section describes files in the design directory.
### `config.mk`
The `config.mk` file describes design-specific variables.
For Example:
```default
DESIGN_NAME
PLATFORM
VERILOG_FILES
SDC_FILE
CORE_UTILIZATION
CORE_ASPECT_RATIO
CORE_MARGIN
PLACE_DENSITY
```
Alternatively, `DIE_AREA` and `CORE_AREA` can be specified instead of
`CORE_UTILIZATION`, `CORE_ASPECT_RATIO`, and `CORE_MARGIN`. For a complete
descriptor of all variables see [here](../user/FlowVariables.md).
Following is a sample `config.mk` file for the `gcd` design:
```shell
export DESIGN_NAME = gcd
export PLATFORM = sky130hd
export VERILOG_FILES = $(sort $(wildcard ./designs/src/$(DESIGN_NAME)/*.v))
export SDC_FILE = ./designs/$(PLATFORM)/$(DESIGN_NAME)/constraint.sdc
export CORE_UTILIZATION = 30
export CORE_ASPECT_RATIO = 1
export CORE_MARGIN = 2
export PLACE_DENSITY = 0.70
```
### `constraint.sdc`
The `constraint.sdc` file defines timing constraints for the design. The
`create_clock` command allows you to define clocks that are either connected
to nets or are virtual and can be customized. The units for `create_clock`
need to be consistent with the liberty time units. Here’s an example of
a `constraint.sdc` file which defines a clock `clk` with a period of 8.4
nanoseconds (nanoseconds being consistent with the liberty time units).
```tcl
create_clock [get_ports clk] -period 8.4 #Units are in nanoseconds
```
Refer to the
[OpenSTA](https://github.com/The-OpenROAD-Project/OpenSTA/blob/master/doc/OpenSTA.pdf)
User Guide for the full documentation of the `create_clock` command.
### Liberty, LEF, and GDS Files
The liberty, LEF, and GDS files do not technically have to reside inside the
platform directory of respective technology as long as the paths set in the
`config.mk` file point to the correct files. However, it is good practice to
have all relevant files in one localized directory. The `.lib`, `.lef`, and
`.gds` reside in directories named respectively for the specific technology.
For example:
```shell
mdkir flow/platforms/MyNewPlatform/lib
mdkir flow/platforms/MyNewPlatform/lef
mdkir flow/platforms/MyNewPlatform/gds
```
A merged GDS file may be used instead of adding every individual `.gds`
file from the standard cell library.
Once the liberty file, tech and macro LEF files, and either the merged
standard cell GDS or individual standard cell GDS files have been generated,
place them in their respective directories and set the `lib`, `lef`, and
`gds` variables in the platform `config.mk` file to the correct paths.
### Clock Gates
Yosys cannot (currently) infer clock gates automatically. However, users can
manually instantiate clock gates in their RTL using a generic interface. The
purpose of this interface is to separate platform-specific RTL (also called
“hardened” RTL) from platform-independent RTL (generic RTL).
This file is only required if you want to instantiate clock gates in your
design.
To create this module, a gated clock standard cell is required. This standard
cell is used to create the generic module `OPENROAD_CLKGATE`, as shown below.
```verilog
module OPENROAD_CLKGATE (CK, E, GCK);
input CK;
input E;
output GCK;
latch (.CLK(CK), .GATE(E), .GCLK(GCK));
endmodule
```
An example instantiation of this module in a user design is shown below.
```verilog
// This is not a platform file, this is an example user design
module buffer (clk, enable, in, out);
input clk, enable;
input [7:0] in,
output [7:0] out
reg [15:0] buffer_reg;
wire gck; // Gated clock
OPENROAD_CLKGATE clkgate (.CK(clk), .E(enable), .GCK(gck));
// Buffer does not change if enable is low
always @(posedge gck) begin
buffer_reg[15:8] <= in;
buffer_reg[ 7:0] <= buffer_reg[15:8];
end
assign out = buffer_reg[ 7:0];
```
### Latches
Yosys can automatically infer latches from RTL, however it requires a behavioral
Verilog module. Example latch definitions are provided below. `DLATCH_P` is an
active-high level-sensitive latch and `DLATCH_N` is an active-low
level-sensitive latch.
This file is only required if you want to infer latches for your design.
```verilog
module $_DLATCH_P_(input E, input D, output Q);
_TECHMAP_REPLACE_ (
.D (D),
.G (E),
.Q (Q)
);
endmodule
module $_DLATCH_N_(input E, input D, output Q);
_TECHMAP_REPLACE_ (
.D (D),
.GN (E),
.Q (Q)
);
endmodule
```
### FastRoute Configuration
FastRoute is the tool used to global-route the design. FastRoute requires a
Tcl file to set which routing layers will be used for signals, adjust routing
layer resources, set which routing heuristic to use when routing, etc. It’s
recommended to use the default `fastroute.tcl` due to its simplicity and
effectiveness. Following is the default FastRoute configuration file.
```tcl
set_global_routing_layer_adjustment $::env(MIN_ROUTING_LAYER)-$::env(MAX_ROUTING_LAYER) 0.5
set_routing_layers -signal $::env(MIN_ROUTING_LAYER)-$::env(MAX_ROUTING_LAYER)
```
The first command, `set_global_routing_layer_adjustment`, adjusts the
routing resources of the design. This effectively reduces the number of
routing tracks that the global router assumes to exist. By setting it to
the value of 0.5, this reduced the routing resources of all routing layers
to 50% which can help with congestion and reduce the challenges for detail
routing. The second command, `set_routing_layers`, sets the minimum and
maximum routing layers for signal nets by using the `-signal` option.
More customization can be done to increase the efficiency of global and
detail route. Refer to the [FastRoute documentation](https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/grt/README.md)
### Metal Tracks Configuration
OpenROAD requires a metal track configuration file for use in
floorplanning. For each metal layer, the x and y offset as well as the x and
y pitch are defined. To find the pitch and offset for both x and y, refer
to the `LAYER` definition section for each metal in the tech LEF. Following
is a generalized metal tracks configuration file with five metal tracks
defined. **Units are in microns**.
```tcl
make_tracks metal1 -x_offset 0.24 -x_pitch 0.82 -y_offset 0.24 -y_pitch 0.82
make_tracks metal2 -x_offset 0.28 -x_pitch 0.82 -y_offset 0.28 -y_pitch 0.82
make_tracks metal3 -x_offset 0.28 -x_pitch 0.82 -y_offset 0.28 -y_pitch 0.82
make_tracks metal4 -x_offset 0.28 -x_pitch 0.82 -y_offset 0.28 -y_pitch 0.82
make_tracks metal5 -x_offset 0.28 -x_pitch 0.82 -y_offset 0.28 -y_pitch 0.82
```
Following is the `LAYER` definition for `metal1` in the `sky130hd` tech LEF.
```default
LAYER met1
TYPE ROUTING ;
DIRECTION HORIZONTAL ;
PITCH 0.34 ;
OFFSET 0.17 ;
WIDTH 0.14 ; # Met1 1
# SPACING 0.14 ; # Met1 2
# SPACING 0.28 RANGE 3.001 100 ; # Met1 3b
SPACINGTABLE
PARALLELRUNLENGTH 0
WIDTH 0 0.14
WIDTH 3 0.28 ;
AREA 0.083 ; # Met1 6
THICKNESS 0.35 ;
MINENCLOSEDAREA 0.14 ;
ANTENNAMODEL OXIDE1 ;
ANTENNADIFFSIDEAREARATIO PWL ( ( 0 400 ) ( 0.0125 400 ) ( 0.0225 2609 ) ( 22.5 11600 ) ) ;
EDGECAPACITANCE 40.567E-6 ;
CAPACITANCE CPERSQDIST 25.7784E-6 ;
DCCURRENTDENSITY AVERAGE 2.8 ; # mA/um Iavg_max at Tj = 90oC
ACCURRENTDENSITY RMS 6.1 ; # mA/um Irms_max at Tj = 90oC
MAXIMUMDENSITY 70 ;
DENSITYCHECKWINDOW 700 700 ;
DENSITYCHECKSTEP 70 ;
RESISTANCE RPERSQ 0.125 ;
END met1
```
In the example above, the x and y pitch for `met1` would be 0.34 and the
x and y offset would be 0.17.
### PDN Configuration
PDN is a utility that simplifies adding a power grid into the floorplan. With
specifications given in the PDN configuration file, like which layer to use,
stripe width and spacing, the utility can generate the metal straps used
for the power grid. To create and configure a power grid, refer to the
[PDN documentation](https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/pdn/README.md).
### Tapcell Configuration
The tapcell configuration file is used to insert tapcells and endcaps into
the design. Refer to the [Tapcell](https://github.com/The-OpenROAD-Project/OpenROAD/tree/master/src/tap) documentation
on how to construct this file.
### setRC Configuration
`setRC` allows the user to define resistances and capacitances for layers
and vias using the `set_layer_rc` command. There is also a command that
allows you to set the resistance and capacitance of routing wires using
the `set_wire_rc`. The units `set_wire_rc` is expecting are per-unit-length
values. Often, per-unit-length values are available in the PDK user guide. For
`set_layer_rc`, Liberty units need to be used. Following is a generic example
of a `setRC` configuration file which sets the resistance and capacitance
of five metal layers, four vias, one signal wire, and one clock wire.
```tcl
set_layer_rc -layer M1 -capacitance 1.449e-04 -resistance 8.929e-04
set_layer_rc -layer M2 -capacitance 1.331e-04 -resistance 8.929e-04
set_layer_rc -layer M3 -capacitance 1.464e-04 -resistance 1.567e-04
set_layer_rc -layer M4 -capacitance 1.297e-04 -resistance 1.567e-04
set_layer_rc -layer M5 -capacitance 1.501e-04 -resistance 1.781e-05
set_layer_rc -via V1 -resistance 9.249146E-3
set_layer_rc -via V2 -resistance 4.5E-3
set_layer_rc -via V3 -resistance 3.368786E-3
set_layer_rc -via V4 -resistance 0.376635E-3
set_wire_rc -signal -layer M2
set_wire_rc -clock -layer M5
```
### KLayout
KLayout is used in the OpenROAD flow to provide GDS merging, DRC, and
LVS. Two files are required for KLayout and they are generated within the
KLayout GUI. Install KLayout on the host machine since it is not included
in the OpenROAD build process. Then create the properties and tech files
as explained below.
### KLayout tech file
Follow these steps to generate the KLayout tech file:
1. Open KLayout in a terminal.
2. Go to Tools -> Manage Technologies.
3. Click the + in the bottom left corner to create a new technology.
4. Set the name for the technology in the box that pops up. You should now see the technology name in the list on the left hand side.
5. Expand the technology by hitting the arrow and click on General.
6. Set the base path your platform directory and load the `.lyp` layer properties file that was generated earlier.
7. On the left hand side under your new technology click Reader Options and then click LEF/DEF on the top bar.
8. In the LEF+Macro Files section, you add the LEF files by clicking the + button on the right hand side of the box.
1. **Note**: Only add your original merged LEF file. Make sure it includes the full path to the LEF file.
9. In the Production section, scroll down and add the layer map file by hitting the Load File button.
1. **Note**: Make sure it includes the full path.
10. Above in the same section, change the layer name suffix and GDS data type to correspond with the layer map.
11. Generate the `.lyt` file by right clicking on the new technology name and click on Export Technology.
12. Save with the extension `.lyt`.
### KLayout properties file
The properties file is not required to obtain a GDS and is merely used for styling purposes inside. Follow these steps to generate the KLayout properties file:
1. Open KLayout.
2. Install the `tf_import` package.
1. Inside KLayout, go to Tools.
2. Manage Packages.
3. Install New Packages.
4. Select `tf_import`.
1. If the source of the package is from GitHub, then the file “” needs to be edited to include “source stdio”.
3. Re-start KLayout.
4. File -> Import some LEF. Does not matter what LEF; you will just get an error message without one…
5. Once selected, go to Options at the bottom left.
6. Select your layer map file under the Production tab.
7. Go to the LEF+Macro Files tab, then add under Additional LEF files, the merged (original) LEF file in your platform directory.
8. Under Macro Layout Files, add the GDS file in your platform directory.
9. File -> Import Cadence tech file.
1. You have to select a tech file (found in the PDK, usually inside the Virtuoso folder).
2. KLayout also needs a `.drf` file which is automatically included if it resides in the same directory the cadence tech file was found in (found in the PDK’s Virtuoso folder)…
10. File -> Save Layer Properties.
11. Save as a `.lyp` file in your platform directory.
## Validating the New Platform
To validate the new platform, simply run a design through the flow using
the new platform. The Makefile should already include the `DESIGN_CONFIG`
variables for the new platform which were generated in the Setup section
of the document. Simply uncomment a `DESIGN_CONFIG` variable for the new
platform in the Makefile, save, and then run `make` in the terminal to run
the design through the flow. Try a small design first (i.e. `gcd`) so that
run time is small and you can identify and fix errors faster.
## Authors/Contributors
* James Stine - Oklahoma State University
* Teo Ene - Oklahoma State University
* Ricardo Hernandez - Oklahoma State University
* Ryan Ridley - Oklahoma State University
* Indira Iyer - OpenROAD Project Consultant
# QoRDashboard.html.md
# Using the OpenROAD Dashboard to track and analyze Quality of Results
The metrics dashboard [(https://dashboard.theopenroadproject.org/)](https://dashboard.theopenroadproject.org/)
is tailored for RTL-to-GDS flow stages, targeting different designs across
various platforms. The dashboard comprises two main pages: the trends
page and the comparison page.
## Trends
The trends page allows users to visualize metric trends through
interactive graphs, enabling the selection of platforms, designs,
and metrics for each platform. This feature aids in tracking the
fluctuations of metrics over time.
## Comparison
The comparison page lets users compare metrics between branches
or commits for a specific platform and its designs. The comparison is
shown as a table showcasing the differences between the
base source and the test source. This page also offers deeper insights,
like the platform summary table that presents statistical trends for
different designs within a platform and a summary table that
provides insights for the set of selected designs, with added
functionality for filtering.
These pages combine to create a comprehensive dashboard facilitating
data-driven decision-making and performance optimization in the
design flow.
# SupportedOS.html.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]()): 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]().
## 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: [https://theopenroadproject.org](https://theopenroadproject.org)
- Twitter: [https://twitter.com/OpenROAD_EDA](https://twitter.com/OpenROAD_EDA)
- Issues and bugs:
- OpenROAD: [https://github.com/The-OpenROAD-Project/OpenROAD/issues](https://github.com/The-OpenROAD-Project/OpenROAD/issues)
- Discussions:
- OpenROAD: [https://github.com/The-OpenROAD-Project/OpenROAD/discussions](https://github.com/The-OpenROAD-Project/OpenROAD/discussions)
- Inquiries: openroad@ucsd.edu
See also our [FAQs](user/FAQS.md).
## Site Map
# TutorialHome.html.md
# OpenROAD-flow-scripts tutorial
The links to the main flow tutorial, where we go through each step of
the RTL-GDSII flow are as [follows](FlowTutorial.md). We have also provided
Google Colab packaging for ease of experimentation [here](Notebooks.md).
# UserGuide.html.md
# User Guide
The OpenROAD Project uses three tools to perform automated RTL-to-GDS layout generation:
1. [yosys](https://github.com/The-OpenROAD-Project/yosys): Logic
Synthesis
2. [OpenROAD](https://github.com/The-OpenROAD-Project/OpenROAD):
Floorplanning through Detailed Routing
3. [KLayout](https://www.klayout.de/): GDS merge, DRC and LVS (public
PDKs)
To automate RTL-to-GDS we provide
[OpenROAD Flow](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts),
which contains scripts that integrate the three tools.
## Code Organization
The [OpenROAD Flow](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts)
repository serves as an example RTL-to-GDS flow using the OpenROAD
tools. The script `build_openroad.sh` in the repository will
automatically build the OpenROAD toolchain.
The two main directories are:
1. `tools/`: contains the source code for the entire yosys and
[OpenROAD App](https://github.com/The-OpenROAD-Project/OpenROAD)
(both via submodules) as well as other tools required for the flow.
2. `flow/`: contains reference recipes and scripts to run designs
through the flow. It also contains public platforms and test
designs.
## Setup
See Getting Started guide.
## Using the OpenROAD Flow
See the documentation [here](../tutorials/FlowTutorial.md) for details about the
flow and how to run designs through the flow.
## Using the OpenROAD App
See the documentation [here](https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/README.md) for details about the app and
the available features and commands.
# index2.html.md
# Welcome to the OpenROAD Flow Scripts 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.
Learn more about the project at our website and our resources page
[here](https://theopenroadproject.org/resources/).
## Getting Started with OpenROAD Flow Scripts
OpenROAD Flow is a full RTL-to-GDS flow built entirely on open-source tools.
The project aims for automated, no-human-in-the-loop digital circuit design
with 24-hour turnaround time. For more information, refer to our repository
[README](mainREADME.md).
### Setup
#### 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` |
#### System Requirements
To build the binaries and run `gcd` through the flow:
- Minimum: 1 CPU core and 8GB RAM.
- Recommended: 4 CPU cores and 16GB of RAM.
#### NOTE
`gcd` is a small design, and thus requires less computational power.
Larger designs may require better hardware.
#### Build or Installing ORFS Dependencies
We support four major ways of installation:
- [Docker](user/BuildWithDocker.md)
- [Pre-built Binaries](user/BuildWithPrebuilt.md)
- [Windows Subsystem for Linux (WSL)](user/BuildWithWSL.md)
- [Local Installation](user/BuildLocally.md)
You may also choose and use the build script to customise your build process.
See more in the next section.
##### Build Command and options
```shell
./build_openroad.sh --help
```
Options for `./build_openroad.sh` script
| Argument | Description |
|-----------------------------|----------------------------------------------------------------------------------------------------------------------|
| `-h` or `--help` | Print help message. |
| `-o` or `--local` | Build locally instead of building a Docker image. |
| `-l` or `--latest` | Use the head of branch –or_branch or ‘master’ by default for tools/OpenROAD. |
| `--or_branch BRANCH_NAME` | Use the head of branch BRANCH for tools/OpenROAD. |
| `--or_repo REPO_URL` | Use a fork at REPO-URL (https/ssh) for tools/OpenROAD. |
| `--no_init` | Skip initializing submodules. |
| `-t N` or `--threads N` | Use N cpus when compiling software. |
| `-n` or `--nice` | Nice all jobs. Use all cpus unless `--threads` is also given, then use N threads. |
| `--yosys-args-overwrite` | Do not use default flags set by this scrip during Yosys compilation. |
| `--yosys-args STRING` | Aditional compilation flags for Yosys compilation. |
| `--openroad-args-overwrite` | Do not use default flags set by this script during OpenROAD app compilation. |
| `--openroad-args STRING` | Aditional compilation flags for OpenROAD app compilation. |
| `--install-path PATH` | Path to install tools. Default is `${INSTALL_PATH}`. |
| `--clean` | Call git clean interactively before compile. Useful to remove old build files. |
| `--clean-force` | Call git clean before compile. WARNING: this option will not ask for confirmation. Useful to remove old build files. |
| `-c` or `--copy-platforms` | Only applicable for docker builds. Copy platforms to inside docker image. |
| `--docker-args-overwrite` | Only applicable for docker builds. Do not use default flags set by this script for Docker builds. |
| `--docker-args STRING` | Only applicable for docker builds. Additional compilation flags for Docker build. |
### Running a Design
Sample design configurations are available in the `designs` directory.
You can select a design using either of the following methods:
1. The flow
[Makefile](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/Makefile)
contains a list of sample design configurations at the top of the
file. Uncomment the respective line to select the design.
2. Specify the design using the shell environment. For example:
```shell
# Make sure you are in ./flow
make DESIGN_CONFIG=./designs/nangate45/swerv/config.mk
# or
export DESIGN_CONFIG=./designs/nangate45/swerv/config.mk
make
```
By default, the `gcd` design is selected using the
`nangate45` platform. The resulting GDS will be available at
`flow/results/nangate45/gcd/6_final.gds`. The flow should take only a few
minutes to produce a GDS for this design. We recommend implementing this
design first to validate your flow and tool setup.
### Design exploration and automatic parameter tuning
AutoTuner is an automatic parameter tuning framework capable of performing
automatic parameter tuning framework for commercial and academic RTL-to-GDS
flows. The two main functionalities that AutoTuner provides are:
- Automatic hyperparameter tuning framework for OpenROAD-flow-scripts
- Parametric sweeping experiments for OpenROAD-flow-scripts
### Adding a Design
To add a new design to the `flow` directory, refer to the document [here](user/AddingNewDesign.md).
### Platforms
OpenROAD-flow-scripts supports Verilog to GDS for the following open platforms:
- ASAP7
- Nangate45 / FreePDK45
- SKY130
- GF180
- SG13G2
These platforms have a permissive license which allows us to
redistribute the PDK and OpenROAD platform-specific files. The platform
files and license(s) are located in `platforms/{platform}`.
OpenROAD-flow-scripts also supports the following proprietary platforms:
- GF55
- GF12
- Intel22
- Intel16
- TSMC65
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, you can create the necessary platform-specific files
yourself.
Once the platform is set up, you can create a new design configuration with
information about the design. See sample configurations in the `design`
directory.
Refer to the [Flow variables](user/FlowVariables.md) document for details on how to use
environment variables in OpenROAD-flow-scripts to configure platform and design specific parameters.
#### Adding a Platform
Refer to the [platform bring up](contrib/PlatformBringUp.md) documentation
to set up a new platform for OpenROAD-flow-scripts.
### Implement the Design
Run `make` to perform Verilog to GDS. The final output will be located
at `flow/results/{platform}/{design_name}/6_final.gds`
### Miscellaneous
#### Smoke-test harness for top-level Verilog designs
1. Drop your Verilog files into `designs/src/harness`
2. Start the workflow:
```shell
make DESIGN_NAME=TopLevelName DESIGN_CONFIG=$(pwd)/designs/harness.mk
```
## 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.
## How to get in touch
We maintain the following channels for communication:
- Project homepage and news: [https://theopenroadproject.org](https://theopenroadproject.org)
- Twitter: [https://twitter.com/OpenROAD_EDA](https://twitter.com/OpenROAD_EDA)
- Issues and bugs:
- OpenROAD Flow: [https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/issues](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/issues)
- OpenROAD with OpenROAD Flow Scripts: [https://github.com/The-OpenROAD-Project/OpenROAD/issues/](https://github.com/The-OpenROAD-Project/OpenROAD/issues/)
- Discussions:
- OpenROAD Flow: [https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/discussions](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/discussions)
- Inquiries: openroad@ucsd.edu
See also our [FAQs](user/FAQS.md).
## Code of conduct
Please read our code of conduct [here](contrib/CODE_OF_CONDUCT.md).
## Site Map
* [User Guide](user/UserGuide.md)
* [Code Organization](user/UserGuide.md#code-organization)
* [Setup](user/UserGuide.md#setup)
* [Using the OpenROAD Flow](user/UserGuide.md#using-the-openroad-flow)
* [Using the OpenROAD App](user/UserGuide.md#using-the-openroad-app)
* [Manpages](Manpage.md)
* [Commands](Manpage.md#commands)
* [Prometheus Metrics](Manpage.md#prometheus-metrics)
* [Man installation](Manpage.md#man-installation)
* [Man](Manpage.md#man)
* [Options](Manpage.md#options)
* [Example scripts](Manpage.md#example-scripts)
* [tee](Manpage.md#tee)
* [Options](Manpage.md#id1)
* [Example scripts](Manpage.md#id2)
* [Regression tests](Manpage.md#regression-tests)
* [Limitations](Manpage.md#limitations)
* [FAQs](Manpage.md#faqs)
* [References](Manpage.md#references)
* [Authors](Manpage.md#authors)
* [License](Manpage.md#license)
* [Getting Involved](contrib/GettingInvolved.md)
* [Licensing Contributions](contrib/GettingInvolved.md#licensing-contributions)
* [Contributing Open Source PDK information and Designs](contrib/GettingInvolved.md#contributing-open-source-pdk-information-and-designs)
* [Contributing Scripts and Code](contrib/GettingInvolved.md#contributing-scripts-and-code)
* [Questions](contrib/GettingInvolved.md#questions)
* [Developer's Guide](contrib/DeveloperGuide.md)
* [Timing and Logging (`run_command.py`)](contrib/DeveloperGuide.md#timing-and-logging-run-command-py)
* [What it does](contrib/DeveloperGuide.md#what-it-does)
* [Usage](contrib/DeveloperGuide.md#usage)
* [Monitoring long-running stages](contrib/DeveloperGuide.md#monitoring-long-running-stages)
* [Cross-platform support](contrib/DeveloperGuide.md#cross-platform-support)
* [Testing](contrib/DeveloperGuide.md#testing)
* [Code of Conduct](contrib/CODE_OF_CONDUCT.md)
* [Our Pledge](contrib/CODE_OF_CONDUCT.md#our-pledge)
* [Our Standards](contrib/CODE_OF_CONDUCT.md#our-standards)
* [Enforcement Responsibilities](contrib/CODE_OF_CONDUCT.md#enforcement-responsibilities)
* [Scope](contrib/CODE_OF_CONDUCT.md#scope)
* [Enforcement](contrib/CODE_OF_CONDUCT.md#enforcement)
* [Enforcement Guidelines](contrib/CODE_OF_CONDUCT.md#enforcement-guidelines)
* [1. Correction](contrib/CODE_OF_CONDUCT.md#correction)
* [2. Warning](contrib/CODE_OF_CONDUCT.md#warning)
* [3. Temporary Ban](contrib/CODE_OF_CONDUCT.md#temporary-ban)
* [4. Permanent Ban](contrib/CODE_OF_CONDUCT.md#permanent-ban)
* [Attribution](contrib/CODE_OF_CONDUCT.md#attribution)
* [FAQs](user/FAQS.md)
* [How can I contribute?](user/FAQS.md#how-can-i-contribute)
* [How do I update OpenROAD-flow-scripts?](user/FAQS.md#how-do-i-update-openroad-flow-scripts)
* [How do I update the design reference files?](user/FAQS.md#how-do-i-update-the-design-reference-files)
* [How do I get better search results?](user/FAQS.md#how-do-i-get-better-search-results)
* [Tutorials](tutorials/TutorialHome.md)
* [Flow QoR and CI Metrics](user/Flow_QoR_CI.md)
* [OpenROAD Dashboard](user/Flow_QoR_CI.md#openroad-dashboard)
* [Jenkins CI](user/Flow_QoR_CI.md#jenkins-ci)
# mainREADME.html.md
# OpenROAD Flow
[](https://jenkins.openroad.tools/view/Public/job/OpenROAD-flow-scripts-Public/job/public_tests_all/job/master/)
[](https://openroad-flow-scripts.readthedocs.io/en/latest/?badge=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.
## Tool Installation
There are multiple ways to install and develop OpenROAD and ORFS. However, the best option depends on your use case, experience level, and personal preference.
> **Recommendation for new users:**
> \\\\
> If you are new to OpenROAD-flow-scripts, Docker can be a reliable way to get started since it avoids most dependency and environment issues.
> On supported platforms, using the pre-built binaries can be an even simpler option as it avoids building from source.
> Alternatively, the Bazel-based flow also avoids manual dependency installation (aside from installing Bazelisk itself), similar to how Docker requires installing Docker.
### Use Bazel, avoid installing anything at all and adapt the flow to your needs in your own repository
[bazel-orfs](https://github.com/The-OpenROAD-Project/bazel-orfs) provides a seamless, reproducible way to manage dependencies and adapt the flow without requiring manual installations(no Docker images, sudo bash scripts, etc.)
By leveraging [Bazel](https://bazel.build/)’s robust build system, all dependencies are automatically resolved, versioned, and built in a consistent environment. This eliminates setup complexity, ensures fast incremental builds, and allows for easy customization of the flow, making it an efficient choice for both [beginners](https://github.com/The-OpenROAD-Project/RegFileStudy) and [advanced](https://github.com/The-OpenROAD-Project/megaboom) users.
### Docker Based Installation
To ease dependency installation issues, ORFS uses docker images.
Docker image includes ORFS binaries, applications as well as all
required dependencies. All of the flow tools are encapsulated
inside the container image.
If `Docker` is not installed already, install latest docker tool
based on OS from [here](https://docs.docker.com/engine/install/).
To manage docker as non-root user and verify that you can run
`docker` commands without `sudo` must complete steps from
[here](https://docs.docker.com/engine/install/linux-postinstall/).
#### Build ORFS with Docker
Document for detailed steps on docker based installation found
[here]().
### Pre-built Binaries
You can download, set up and run ORFS easily with pre-built
binaries, including OpenROAD, Yosys and Klayout. See instructions
[here]().
> **Thanks** to [Precision Innovations](https://precisioninno.com/) for
> providing and supporting OpenROAD based binaries.
> **Note** Only the latest version of OpenROAD is guaranteed to work with
> the latest version of ORFS.
> **Disclaimer** The versions of OpenROAD, Yosys and Klayout provided by
> other third-party vendors are not guaranteed to work with ORFS.
### Build from sources locally
Document for detailed local build from sources and installation steps found [here]().
## Using the Flow
- For details about the OpenROAD and the available features and
individual flows commands, see the documentation
[here](https://openroad.readthedocs.io/en/latest/).
- For details about automated flow setup, see ORFS docs
[here](https://openroad-flow-scripts.readthedocs.io/en/latest/index2.html#getting-started-with-openroad-flow-scripts).
- Flow tutorial to run the complete OpenROAD based flow from
RTL-GDSII, see the tutorial
[here](https://openroad-flow-scripts.readthedocs.io/en/latest/tutorials/FlowTutorial.html).
- To watch ORFS flow tutorial videos, check
[here](https://theopenroadproject.org/video).
## Building from your own git repository
ORFS supports hosting projects in your own git repository
without the need to fork ORFS.
To build from your own git repository:
```none
cd /home/me/myproject
make --file=~/OpenROAD-flow-scripts/flow/Makefile DESIGN_CONFIG=somefolder/config.mk ...
```
## Running a quick smoke-test of ORFS on your own Verilog
You can [run ORFS on your own Verilog files]()
without setting up a project or moving your Verilog files and even learn
a thing or two about floorplan, placement and routing
before you create an .sdc file and a config.mk file.
## Citing this Work
If you use this software in any published work, we would appreciate a citation!
Please use the following references:
```default
@article{ajayi2019openroad,
title={OpenROAD: Toward a Self-Driving, Open-Source Digital Layout Implementation Tool Chain},
author={Ajayi, T and Blaauw, D and Chan, TB and Cheng, CK and Chhabria, VA and Choo, DK and Coltella, M and Dobre, S and Dreslinski, R and Foga{\c{c}}a, M and others},
journal={Proc. GOMACTECH},
pages={1105--1110},
year={2019}
}
```
A copy of this paper is available
[here](http://people.ece.umn.edu/users/sachin/conf/gomactech19.pdf) (PDF).
```default
@inproceedings{ajayi2019toward,
title={Toward an open-source digital flow: First learnings from the openroad project},
author={Ajayi, Tutu and Chhabria, Vidya A and Foga{\c{c}}a, Mateus and Hashemi, Soheil and Hosny, Abdelrahman and Kahng, Andrew B and Kim, Minsoo and Lee, Jeongsup and Mallappa, Uday and Neseem, Marina and others},
booktitle={Proceedings of the 56th Annual Design Automation Conference 2019},
pages={1--4},
year={2019}
}
```
A copy of this paper is available
[here](https://vlsicad.ucsd.edu/Publications/Conferences/371/c371.pdf) (PDF).
If you like the tools, please give us a star on our GitHub repos!
## License
The OpenROAD-flow-scripts repository (build and run scripts) has a BSD 3-Clause License.
The flow relies on several tools, platforms and designs that each have their own licenses:
- Find the tool license at: `OpenROAD-flow-scripts/tools/{tool}/` or `OpenROAD-flow-scripts/tools/OpenROAD/src/{tool}/`.
- Find the platform license at: `OpenROAD-flow-scripts/flow/platforms/{platform}/`.
- Find the design license at: `OpenROAD-flow-scripts/flow/designs/src/{design}/`.