Games / Command flash cards / OpenROAD-flow-scripts variables / Design and platform

Design and platform

Each card shows a command to explain. A missed card returns later in the round and starts the schedule over. A card answered correctly moves up the schedule and next appears after 1, 3, 7, then 21 days. Keys 1 to 4 choose an option, h shows a hint, and Enter moves on. A hint keeps the card where it is on the schedule. An ordering card is answered by clicking its items in order, and one wrong click ends it. Time values are in nanoseconds. Progress is stored in this browser.

SourceThese cards cover the make variables that drive OpenROAD-flow-scripts, the reference flow built on OpenROAD. Each card shows a line as it appears in a design's or a platform's config.mk, and each answer links to that variable in the flow's own variable reference. Variables come and go between releases; this deck follows the version in the openroad/orfs image. Reference: flow variable reference (OpenROAD-flow-scripts on GitHub).

All 10 cards in this section, with answers

export DESIGN_NAME = gcd

Names the top-level module that the flow builds.

Hint: The flow has to know which module is the design, out of everything it reads.

Every stage works on this module, and it must match a module in the Verilog that is read. DESIGN_NICKNAME is the separate variable that renames the output directory. OpenROAD-flow-scripts reference
export DESIGN_NICKNAME = riscv32i

Changes the output directory name without changing the module built.

Hint: Compare it with DESIGN_NAME: only one of the two has to match the Verilog.

Results go to results/<platform>/<nickname>/. It exists for designs whose top module name is unwieldy or collides with another design's. OpenROAD-flow-scripts reference
export PLATFORM = nangate45

Selects the process design kit the design is built with.

Hint: One word pulls in a whole directory of technology files.

The platform directory supplies the technology and cell files, the site, the power grid script, and its own default variables. Changing this one line rebuilds the same design on a different technology. OpenROAD-flow-scripts reference
export VERILOG_FILES = $(sort $(wildcard ./designs/src/gcd/*.v))

Lists the design's source files for synthesis to read.

Hint: Ask what synthesis is given to read.

The list is read by synthesis, in order. sort around a wildcard keeps the order stable so a build is repeatable. Header directories are given separately with VERILOG_INCLUDE_DIRS. OpenROAD-flow-scripts reference
export SDC_FILE = ./designs/nangate45/gcd/constraint.sdc

Gives the timing constraints, starting with the clock definition.

Hint: It is read early and then used by every stage that thinks about timing.

The file holds the SDC (Synopsys Design Constraints) commands: clock definitions, input and output delays, and any exceptions. Synthesis, placement, clock tree synthesis, and routing all read it, and later stages read the version each earlier stage wrote. OpenROAD-flow-scripts reference
export ADDITIONAL_LEFS = ./designs/src/tiny/sram.lef

Adds hard macro geometry: outline, pins, and blockages.

Hint: A hardened macro is not in the standard cell library. Ask what its shape comes from.

A macro needs three things in the flow: its shape from a LEF (Library Exchange Format) file here, its timing from ADDITIONAL_LIBS, and its layout from ADDITIONAL_GDS at the end. The shape is stored in the design database; the timing is not. OpenROAD-flow-scripts reference
export ADDITIONAL_LIBS = ./designs/src/tiny/sram.lib

Adds hard macro timing and power data for analysis.

Hint: The counterpart of the macro's shape.

The library is read in each session that times the design, because it is not stored in the database, unlike the geometry. A macro missing from here times as if it had no delay at all. OpenROAD-flow-scripts reference
export ADDITIONAL_GDS = ./designs/src/tiny/sram.gds

Adds the macro's real layout for the final merged layout file.

Hint: It matters only at the very end, when one file has to contain everything.

Through the flow a macro is only an outline with pins. The finishing stage merges the real layout of each macro into the design's own layout, which is what goes to the foundry. OpenROAD-flow-scripts reference
export BLOCKS = aes_cipher_top

Names sub-blocks that are hardened first and used as macros above.

Hint: It turns part of your own design into something the top level treats as a macro.

In a hierarchical run each named block goes through the flow on its own and produces an abstract and a timing model. The top level then places it as a macro, which is how a design too big for one flat run is built. OpenROAD-flow-scripts reference
export TECH_LEF = $(PLATFORM_DIR)/lef/NangateOpenCellLibrary.tech.lef export SC_LEF = $(PLATFORM_DIR)/lef/NangateOpenCellLibrary_macro.lef

Gives the technology layers in one file and the cell shapes in the other.

Hint: Two files in the same format, describing two different things.

The technology file carries the metal layers, vias, sites, and spacing rules; the cell file carries each standard cell's outline, pins, and blockages. Both are LEF (Library Exchange Format), and both come from the platform. OpenROAD-flow-scripts reference