Floorplan

Hint: Utilization relates cell area to core area. Ask what the command can derive from it.

Rows are made as well. The core area is the design's cell area divided by the utilization; the aspect ratio turns that into width and height, and -core_space adds the margin between core and die. The site sets the row height. Rows for the site are created, and any existing tracks are removed. OpenROAD reference

Hint: Two rectangles are given. Ask which one the cells go in and what the difference is for.

The core is filled with rows. Giving the two areas explicitly is the alternative to giving a utilization; setting both leads to unexpected results. The margin between die and core holds the power ring and the boundary pins. Rows are built inside the core from the given site. OpenROAD reference

Hint: initialize_floorplan removes tracks. Ask what has to put them back.

Tracks are the legal wire centre lines that the router and the pin placer use. initialize_floorplan removes existing tracks, so they are made again per layer, usually from the technology's own values. OpenROAD reference

Hint: Horizontal and vertical describe the direction of the tracks a pin shape sits on.

Each pin's shape goes on a track of the given layers: pins on horizontal tracks use -hor_layers, pins on vertical tracks on -ver_layers. The placer chooses positions that shorten the nets to the cells inside, and it creates a metal shape that meets the minimum-area rule. OpenROAD reference

Hint: Compare it with place_pins, which does every pin at once.

The location and size are fixed, not a suggestion. It is used for pins that must sit at an agreed place, for example to meet a package or a neighbouring block. write_pin_placement writes a file of these commands so a placement can be reproduced exactly. OpenROAD reference

Hint: It says nothing about when pins move. Ask what it changes for a later command.

The constraint applies to the following place_pins call. A region is an edge and an interval, so left:15-60 would use only part of that edge. -group keeps a list of pins together and -mirrored_pins places pairs symmetrically. OpenROAD reference

Hint: The name says RTL (Register Transfer Level): the placer reads the netlist hierarchy.

-halo_width keeps a 5 micron band clear around each macro. The Hier-RTLMP algorithm clusters the netlist into a hierarchy of soft blocks, shapes them, and then places the macros. The halo is the keepout kept around each macro so standard cells and routing are not pinched against it. OpenROAD reference

Hint: This is the manual counterpart to the automatic macro placer.

The location is the macro's lower-left corner in microns and the orientation is a LEF (Library Exchange Format) orientation such as R0 or MX. -exact and -allow_overlap relax the checks the command otherwise applies. OpenROAD reference

Hint: A halo is empty space, not a physical object.

Cells packed against a macro edge leave no room for the macro's pins to be reached, and for the repair steps that follow. The halo reserves that room. set_macro_extension does the same job for the macro placer's own spacing between macros. OpenROAD reference

Hint: Well taps tie the wells to the supplies; ask what pattern they must follow.

-distance is the tap pitch and -endcap_master the cell that ends a row. Foundry rules limit how far any transistor may be from a well tap, so taps are placed on a checkerboard at that pitch. Endcaps terminate the rows so the wells and implants end legally. Both go in before placement. OpenROAD reference

Hint: A row that runs under a macro is not usable. Ask what to do about it.

Rows must not run through a macro, so they are cut around it, plus the halo given here, plus a halo so cells do not crowd the macro edge. -row_min_width and -row_min_height drop the fragments left behind that are too small to use. OpenROAD reference

Hint: The -soft flag is the interesting part: ask what a soft rule allows.

-soft is the difference: a hard blockage keeps every instance out, while a soft blockage steers the global placer away while allowing cells if the placement needs them, and -max_density instead caps how full the region may get. -inst attaches the blockage to one instance. OpenROAD reference

Hint: Ask how you would get exactly these macro positions back in a later run.

Automatic macro placement is not repeatable across tool versions, and a reviewed floorplan should not change under you. Writing the result as place_macro commands freezes it, and later runs source the file. write_pin_placement does the same for pins. OpenROAD reference

Hint: Compare it with tapcell, which takes many more options.

tapcell does taps, endcaps, and corner cells together from one long list of masters. This narrower command does the tap checkerboard alone, which suits a flow that places its boundary cells with place_endcaps. OpenROAD reference

1. initialize_floorplan
2. pdngen
3. global_placement
4. clock_tree_synthesis
5. detailed_route

Hint: Each one needs something the one before it created.

Rows and a core area come first, then the grid, which must exist before cells are placed over it. The clock tree needs the registers placed, and routing needs the tree. Running these out of order does not usually fail cleanly; it produces a worse result. OpenROAD reference

Hint: Three of these need the thing the fourth one creates.

The command creates the core, the rows, and the routing tracks, either from a target utilization as here or from an explicit die area, plus the site the rows are built from. Pins, taps, and placement all need those rows. A design read from a layout file already has them. OpenROAD reference