3.3. OpenROAD Place-and-Route Tool Plugin
3.3.1. Tool Setup
3.3.2. Tool Steps
__init__.py for the implementation of these steps.
# INITIALIZE init_design # FLOORPLAN floorplan_design place_bumps macro_placement place_tapcells power_straps # PLACE global_placement io_placement resize detailed_placement # CTS clock_tree clock_tree_resize add_fillers ## ROUTING global_route global_route_resize detailed_route # FINISHING extraction write_design
3.3.3. Step Details
A few of the steps are detailed below, mainly to document some details that aren’t present in the comments within the plugin.
The plugin (
defaults.yml) is still the best reference for what each step does, the explanations below are just more nuanced.
126.96.36.199. Macro Placement
At the beginning of the
floorplan_design step, a file called
macros.txt will be generated in
build/par-rundir that lists for each macro: their name/path in the design, master cell name, width/height, and origin (x,y). These may help in setting the
vlsi.inputs.placement_constraints key in your design configuration.
Currently, there are two ways to place macros.
generate (default value), use the
vlsi.inputs.placement_constraints key to specify the path and (x,y) coordinate of each macro in the design. The placement constraints for ALL macros must be specified, or OpenROAD will eventually throw an error about an unplaced instance.
Note that the (x,y) position is fixed to the bottom left corner of the macro, then the orientation is applied. This means that for rotations besides
r0, the (x,y) position WILL NOT correspond to the bottom left corner of the final placed macro (e.g. the (x,y) position for a macro with orientation
mx will correspond to the top left corner of the final placed macro). To get around this, when
bottom_left (default value), the placement (x,y) coordinates are translated based on the rotation of the macro and the width/height specified in the
vlsi.inputs.placement_constraints, so that the (x,y) position specified in
vlsi.inputs.placement_constraints corresponds with the bottom left corner of the final placed macro. If
rotated, then the (x,y) position of the macro is not translated.
auto_macro, you must still use the
vlsi.inputs.placement_constraints key to specify the top-level width/height and margins constraints of the chip, but all macros will be placed automatically using OpenROAD’s
macro_placement command, leading to poor-quality but sane results.
188.8.131.52. Write Design
OpenROAD uses an external tool called KLayout, which executes a custom Python script
par.openroad.def2stream_file for this file’s path)
to write the final design to a GDS file.
This is the same process used in the default VLSI flow from OpenROAD.
3.3.4. Issue Archiving
This plugin supports generating a
tar.gz archive of the current
build/par-rundir directory with a
runme.sh script to reproduce the results.
This feature is enabled with the
par.openroad.create_archive_mode YAML key, which can take the following values:
none- never create an archive (default)
after_error- if OpenROAD errors, create an archive of the run
always- create an archive after every par run (regardless of whether OpenROAD errors)
latest_run- create an archive of latest par run (don’t run OpenROAD)
useful if OpenROAD gets stuck on endless optimization iterations but never actually “errors”
Creating an archive does the following:
Generates a issue directory based on the date/time, top module, OS platform
Dumps the logger output
Generates a runme.sh script
Copies .tcl, .sdc, .pdn, and .lef files in par-rundir to the issue dir
Copies all input Verilog to issue dir
Copies all input LEFs to issue dir (some may not be used since they are hacked in read_lef())
Copies all input LIBs to issue dir
Hacks copied par.tcl script to remove all abspaths
Hacks copied par.tcl script to comment out write_gds block w/ KLayout
Tars up issue dir