63 KiB
Flow Configuration Variables
This page is the comprehensive manual for user-configurable flow variables and their default values. Variables that are defined by the PDK configuration support files and not the flow itself are listed in this chapter.
:::{admonition} A couple things to keep in mind
-
This is a comprehesive list- there are many variables here you would never need to touch. If you want just a brief list of variables you should be using, see the usage guide Hardening Macros.
-
Deprecated variables are automatically translated to their new names for at least 6 months. Removed variables will be entirely ignored by the flow.
-
Variables prefixed
RUN_enable or disable a certain step as part of the larger OpenLane flow, not when calling the relevant function standalone. For example, if RUN_DRT is set 0, but callingdetailed_routingin interactive mode will still run detailed routing. :::
General
The `` `include `` directive is *not* supported in Verilog files. List all the
files you may be depending on, including headers, in `VERILOG_FILES`.
Macros/Chip Integration
Linting
- If you're running a hierarchical design (i.e. one that incorporates Macros
or directly instantiates SCLs), Linting may not work correctly. You have two
options:
- Provide blackboxes for all gate-level models instantiated by the top level
design or any of its macros.
- Files in
VERILOG_FILES_BLACKBOXwill not be included by default.
- Files in
- Disable linting altogether.
- Provide blackboxes for all gate-level models instantiated by the top level
design or any of its macros.
‡ Variable previously prefixed
VERILATOR_have had their prefix changed toLINTER_. The replaced variable is deprecated and will be translated to its new form automatically by the flow.
Synthesis
Static Timing Analysis (STA)
Floorplanning (FP)
Deprecated I/O Layer variables
These variables worked initially, but they were too sky130 specific and will be removed. Currently, if you define them in your design, they'll be used, but it's recommended to update your configuration to use FP_IO_HLAYER and FP_IO_VLAYER, which are defined in the PDK.
All Resizer (RSZ) Steps
Global and Detailed Placement (GPL/DPL)
| Variable | Description |
|---|---|
PL_TARGET_DENSITY |
The desired placement density of cells. It reflects how spread the cells would be on the core area. 1 = closely dense. 0 = widely spread (Default: ($::env(FP_CORE_UTIL) + 10 + (5 * $::env(GPL_CELL_PADDING)) ) / 100.0) |
PL_TIME_DRIVEN |
Specifies whether the placer should use time driven placement. 0 = false, 1 = true (Default: 1) |
PL_BASIC_PLACEMENT |
Specifies whether the placer should run basic placement. Basic placement is used for extremely simple, low-density designs of only a few dozens of gates, and should be disabled for most designs. 0 = false, 1 = true (Default: 0) |
PL_SKIP_INITIAL_PLACEMENT |
Specifies whether the placer should run initial placement or not. 0 = false, 1 = true (Default: 0) |
PL_RANDOM_GLB_PLACEMENT |
Specifies whether the placer should run random placement or not. This is useful if the design is tiny (less than 100 cells). 0 = false, 1 = true (Default: 0) |
PL_RANDOM_INITIAL_PLACEMENT |
Specifies whether the placer should run random placement or not followed by replace's initial placement. This is useful if the design is tiny (less than 100 cells). 0 = false, 1 = true (Default: 0) |
PL_ROUTABILITY_DRIVEN |
Specifies whether the placer should use routability driven placement. 0 = false, 1 = true (Default: 1) |
PL_RESIZER_TIE_SEPERATION |
Distance between load and an inserted tie cell in microns. (Default: 0) |
PL_RESIZER_DESIGN_OPTIMIZATIONS |
Specifies whether resizer design optimizations should be performed or not. 0 = false, 1 = true (Default: 1) |
PL_RESIZER_TIMING_OPTIMIZATIONS |
Specifies whether resizer timing optimizations should be performed or not. 0 = false, 1 = true (Default: 1) |
PL_RESIZER_MAX_WIRE_LENGTH |
Specifies the maximum wire length cap used by resizer to insert buffers. If set to 0, no buffers will be inserted. Value in microns. (Default: 0) |
PL_RESIZER_MAX_SLEW_MARGIN |
Specifies a margin for the slews in percentage. (Default: 20) |
PL_RESIZER_MAX_CAP_MARGIN |
Specifies a margin for the capacitances in percentage. (Default: 20) |
PL_RESIZER_HOLD_SLACK_MARGIN |
Specifies a time margin for the slack when fixing hold violations. Normally the resizer will stop when it reaches zero slack. This option allows you to overfix. (Default: 0.1ns.) |
PL_RESIZER_SETUP_SLACK_MARGIN |
Specifies a time margin for the slack when fixing setup violations. (Default: 0.05ns) |
PL_RESIZER_HOLD_MAX_BUFFER_PERCENT |
Specifies a max number of buffers to insert to fix hold violations. This number is calculated as a percentage of the number of instances in the design. (Default: 50) |
PL_RESIZER_SETUP_MAX_BUFFER_PERCENT |
Specifies a max number of buffers to insert to fix setup violations. This number is calculated as a percentage of the number of instances in the design. (Default: 50) |
PL_RESIZER_ALLOW_SETUP_VIOS |
Allows setup violations when fixing hold. (Default: 0) |
PL_WIRELENGTH_COEF |
Global placement initial wirelength coefficient. Decreasing the variable will modify the initial placement of the standard cells to reduce the wirelengths. (Default: 0.25). |
DONT_USE_CELLS |
The list of cells to not use during resizer optimizations. (Default: the contents of DRC_EXCLUDE_CELL_LIST) |
PL_ESTIMATE_PARASITICS |
Specifies whether or not to run STA after global placement using OpenROAD's estimate_parasitics -placement and generates reports under logs/placement. 1 = Enabled, 0 = Disabled. (Default: 1) |
PL_OPTIMIZE_MIRRORING |
Specifies whether or not to run an optimize_mirroring pass whenever detailed placement happens. This pass will mirror the cells whenever possible to optimize the design. 1 = Enabled, 0 = Disabled. (Default: 1) |
PL_RESIZER_BUFFER_INPUT_PORTS |
Specifies whether or not to insert buffers on input ports whenever resizer optimizations are run. For this to be used, PL_RESIZER_DESIGN_OPTIMIZATIONS must be set to 1. 1 = Enabled, 0 = Disabled. (Default: 1) |
PL_RESIZER_BUFFER_OUTPUT_PORTS |
Specifies whether or not to insert buffers on output ports whenever resizer optimizations are run. For this to be used, PL_RESIZER_DESIGN_OPTIMIZATIONS must be set to 1. 1 = Enabled, 0 = Disabled. (Default: 1) |
PL_RESIZER_REPAIR_TIE_FANOUT |
Specifies whether or not to repair tie cells fanout whenever resizer optimizations are run. For this to be used, PL_RESIZER_DESIGN_OPTIMIZATIONS must be set to 1. 1 = Enabled, 0 = Disabled. (Default: 1) |
PL_MAX_DISPLACEMENT_X |
Specifies how far an instance can be moved along the X-axis when finding a site where it can be placed during detailed placement. (Default: 500μm) |
PL_MAX_DISPLACEMENT_Y |
Specifies how far an instance can be moved along the Y-axis when finding a site where it can be placed during detailed placement. (Default: 100μm) |
PL_MACRO_HALO |
Macro placement halo. Format: {Horizontal} {Vertical} (Default: 0 0μm). |
PL_MACRO_CHANNEL |
Channel widths between macros. Format: {Horizontal} {Vertical} (Default: 0 0μm). |
MACRO_PLACEMENT_CFG |
Specifies the path to a file that instructs OpenLane how and where to place certain macros. For information about the format of this file, see Macro placement configuration. |
UNBUFFER_NETS |
Deprecated: Use RSZ_DONT_TOUCH_RX: A regular expression used to match nets from which to remove buffers after every resizer run. Useful for analog ports in mixed-signal designs where OpenROAD may sometimes add a buffer. |
DONT_BUFFER_PORTS |
Removed: Use RSZ_DONT_TOUCH_RX: Semicolon;delimited list of nets from which to remove buffers. |
Macro placement configuration
MACRO_PLACEMENT_CFG specifies a file (often called macro.cfg or macro_placement.cfg) listing macros (i.e. already-hardened design layouts) to be placed as submodules within the layout being hardened. For example, using JSON configuration:
"MACRO_PLACEMENT_CFG": "dir::macro.cfg",
In that specified macro.cfg file each non-blank/non-comment line declares: a single macro to be included; where it is to be placed; and whether it is to be rotated or mirrored. This example places 3 macros:
# Some macros:
my_controller 100 150 N
your_device 1200 1400 FS # Face south by flipping upside-down.
# Another macro of some kind:
our_bridge 200 800 S
Each line comprises 4 parameters (separated by any amount of whitespace but formatted as columns in this example for readability), and they are as follows:
- Name of the macro (e.g.
my_controller). - Horizontal placement of the macro (e.g.
100, which is 100µm). This is the horizontal offset from the parent layout's left edge, to the macro's left edge. - Vertical placement (e.g.
150, or 150µm). Vertical offset from the parent's bottom edge to the macro's bottom edge. - Orientation specifier (e.g.
N, meaning the macro's own North or top edge points in the North direction, and hence is not rotated).
The N orientation is used most often, but sometimes it is necessary to rotate and/or flip macros. The orientation specifier follows the LEF/DEF language reference, and can be one of the following:
| Orientation | Effect | Result |
|---|---|---|
N or R0 |
No rotation | Macro's "top" faces North. |
S or R180 |
Rotate 180° | Macro's "top" faces South, by rotation. |
W or R90 |
Rotate 90° anti-clockwise | Macro's "top" faces West, by rotation. |
E or R270 |
Rotate 90° clockwise | Macro's "top" faces East, by rotation. |
FN or MY |
Mirror about the Y axis | Macro's "top" faces North and is flipped left-to-right. |
FS or MX |
Mirror about the X axis | Macro's "top" faces South by being flipped top-to-bottom. |
FW or MXR90 |
Mirror about X, rotate 90° anti-clockwise | Macro's "top" faces East by flipping W left-to-right. |
FE or MYR90 |
Mirror about Y, rotate 90° anti-clockwise | Macro's "top" faces West by flipping E right-to-left. |
:::{note}
The alternative names (R0, MXR90, etc.) follow the OpenAccess database format, and specifically these 8 alternatives are also supported by OpenLane.
:::
:::{note} Be careful if using East/West orientations: Ensure the macro's PDN is still able to properly intersect/connect with the parent layout's PDN. :::
For more information on integrating macros and other relevant configuration variables, see:
- Macros/Chip Integration
FP_PDN_MACRO_HOOKSEXTRA_SPEFSCLOCK_NET(which can be an array to specify multiple clock nets if needed) andCLOCK_PORT
Clock Tree Synthesis (CTS)
Global and Detailed Routing (GRT/DRT)
‡ Variable previously prefixed
GLB_RT_have had its prefix changed toGRT_. The replaced variable is deprecated and will be translated to its new form automatically by the flow.
Custom Diode Insertion Scripts
| Variable | Description |
|---|---|
RUN_HEURISTIC_DIODE_INSERTION |
Runs a script by Sylvain Munaut that inserts diodes heuristically based on . 1 = Enabled, 0 = Disabled (Default: 0) |
HEURISTIC_ANTENNA_THRESHOLD |
Minimum manhattan distance of a net to insert a diode in microns. Only applicable for RUN_HEURISTIC_DIODE_INSERTION is enabled. (Default: 90) |
DIODE_ON_PORTS |
Insert diodes on ports with the specified polarities. Available options are none, in, out and both. (Default: none) |
Parasitic Resistance/Capacitance Extraction (RCX)
IR Drop Analysis
| Variable | Description |
|---|---|
RUN_IRDROP_REPORT |
Creates an IR Drop report using OpenROAD PSM. 1 = Enabled, 0 = Disabled. (Default: 1) |
VSRC_LOC_FILES |
Map of voltage source nets to OpenROAD PSM location files. Variable should be provided as a Tcl dict, i.e.: net1 file1 net2 file2. See this for more info. (Default: None) |
Signoff
Magic
- Tim Edwards's Explanation on disabling hier gds: The following is an explanation by Tim Edwards, provided in a slack thread, on how this affects the GDS writing process: "Magic can take a very long time writing out GDS while checking hierarchical interactions in a standard cell layout. If your design is all digital, I recommend using "gds *hier write disable" before "gds write" so that it does not try to resolve hierarchical interactions (since by definition, standard cells are designed to just sit next to each other without creating DRC issues). That can actually make the difference between a 20 hour GDS write and a 2 minute GDS write. For a standard cell design that takes up the majority of the user space, a > 24 hour write time (without disabling the hierarchy checks) would not surprise me."