Chip Tutorial 4: OpenROAD Place, PDN, and Route to DEF

This article is Part 4 of a university-style chip tutorial on a quadrature rotary encoder with an I2C register interface. Part 1 framed the mechanical and electrical problem of the quadrature encoder. Part 2 turned the contract into synthesizable RTL and verified the datapath under Icarus Verilog. Part 3 mapped that RTL onto sky130 standard cells with Yosys and left you a gate-level netlist. Part 4 asks the next question: how do you turn that netlist into a physical design—cells on a die, power delivered, wires routed—and write a DEF a layout tool can import?

You can download the accompanying sources from here. Unpack the zip anywhere on your computer; it creates a folder named quad-encoder-i2c-openroad with synth/, openroad/, and a Makefile. Work inside that folder for every command below. The gate-level netlist is the same generation as Part 3; what is new is the OpenROAD Tcl driver that floorplans, places, builds a teaching power grid, routes, and writes openroad/out/encoder_top.def.

The hardware contract is unchanged and short: decode in ×2 mode (count only edges on A); hold a saturating unsigned 32-bit position; on a rising edge of Z load 0x8000_0000; a soft clear writes zero; the I2C slave sits at address 0x42 and returns little-endian data; a host latch of the live count happens when the register pointer is set to 0x00. Physical design places and wires this design; it does not rewrite the contract. The top module remains encoder_top.

---

What is OpenROAD — and what can it do?

OpenROAD is an open-source engine for the physical design of digital ASICs. Where Yosys spoke in gates and Liberty functions, OpenROAD speaks in microns, rows, tracks, and metal layers. In everyday terms: you hand it a bag of characterized standard cells and a floorplan outline; it decides where each cell sits, how power reaches those cells, and how signal wires connect their pins without violating the manufacturing rules encoded in the technology LEF.

You drive that work with Tcl. A typical teaching chain looks like: read TechLEF and cell LEF → read Liberty → read the gate-level Verilog → link_design → initialize_floorplan → make_tracks → place_pins → global and detailed placement → tap and filler cells → PDN (power distribution network) → global and detailed route → write_def. Nothing in that chain requires clicking through a GUI, though OpenROAD’s GUI is useful for screenshots and debugging. The script is the source of truth.

Larger wrapper flows such as LibreLane exist and can automate more of a tapeout recipe; this tutorial stays on bare OpenROAD Tcl so every command stays readable end to end.

What OpenROAD is not: it is not a logic synthesizer (that was Part 3). It is not a polygon editor (Part 5 uses LayoutEditor for DEF→GDS). DRC and a short LVS note belong with Part 5 (DEF→GDS in LayoutEditor); this series has no Part 6. And a successful place-and-route run is still not a proof that the hardware contract holds—that remains a simulation job from earlier parts.

---

What you get — and what you do not

When the Part 4 script finishes successfully, you get a DEF (Design Exchange Format) file: openroad/out/encoder_top.def. DEF is the ASCII interchange that names the die outline, standard-cell rows, placed components, pins, and—after routing—nets and special power nets in foundry-facing coordinates. You also get a console line from report_design_area with design area and utilization. On the verified teaching die those numbers land near 4736 µm² and about 66% utilization; your OpenROAD version may differ by a few percent.

What you do not get in Part 4:

• GDSII or any mask polygons (Part 5).
• Foundry signoff (Part 5 teaches DRC/LVS vocabulary on the GDS, not foundry signoff).
• A padframe, IO cells, or package balls.
• Proof that the ×2 / Z / I2C contract still holds—re-run simulation if you change RTL.

Keeping those boundaries clear prevents the most common beginner confusion: seeing a dense OpenROAD screenshot and believing a chip has been drawn for the foundry. Part 4 ends when the DEF writes. Everything polygonal is later.

---

sky130 open PDK vs typical foundry PDKs

This series uses the SkyWater 130 nm open PDK (sky130 / sky130A, standard cells sky130_fd_sc_hd)—the same family Part 3 used for Liberty. An open PDK means the technology LEF, cell LEF, and Liberty files are publicly obtainable (for example through ciel). You can run the flow on your own computer without signing an NDA first.

That is unusual. Most commercial foundry PDKs sit behind a non-disclosure agreement: process documents, LEF abstracts, and Liberty corners ship only after a contract. Those PDKs are fine for production silicon; they are a poor fit for a public tutorial that every reader must reproduce. The figure below is a factual teaching contrast, not a product pitch.

Honest brief: most commercial foundry PDKs need an NDA; sky130 does not. We stay on sky130 so the LEF and Liberty paths in the zip resolve the same way on every machine that has installed the open PDK.

---

Tools on your machine

Everything in this article is meant to be reproduced on your own computer. You will need:

• OpenROAD (openroad on your PATH) — to run openroad/run_minimal.tcl.
• make — optional; the zip’s Makefile wraps the same command as make openroad (alias make or).
• A sky130 PDK tree with TechLEF, cell LEF, and Liberty for sky130_fd_sc_hd (same corner family as Part 3: tt_025C_1v80).
• The Part 3 gate-level netlist synth/encoder_top_gl.v (included in the zip).

A quick sanity check before you continue:

openroad -version
ls synth/encoder_top_gl.v

If openroad is missing, fix the install before chasing PDK paths. Route errors that look mysterious are sometimes just “the binary never started.”

Point the script at your PDK through environment variables—never by pasting someone else’s absolute home directory into the Tcl:

export PDK_ROOT=/path/to/your/pdk/root   # directory that contains sky130A/
export PDK=sky130A                        # default

Alternatively set TECH_LEF, CELL_LEF, and LIBERTY to absolute file paths. LayoutEditor users who already keep a local sky130 tree can reuse that install the same way; only the directory on disk differs.

You do not need a layout editor for Part 4 itself. Viewing the DEF in LayoutEditor is fine for curiosity; converting DEF to GDS is the job of Part 5.

---

Minimize die area — try small, then fill until route works

Yosys stat summed abstract cell areas. OpenROAD chooses a real die outline. The pedagogical goal here is as small as practical, not a generous empty square that routes on the first try and teaches nothing about congestion.

The method is a loop: try a tight floorplan → place → build PDN → route. If legalization fails or detailed route leaves violations, enlarge the die slightly or adjust fill and decap. If route completes, keep the size and read design area and utilization from your log—not from a screenshot guess.

Two sizes make the lesson concrete. A 200×200 µm die routes comfortably but sits near 20% utilization—half the picture is filler with little signal metal. That oversized result is a useful anti-example: place-and-route “worked,” yet you paid for empty silicon.

The locked teaching die for this part is 95×95 µm, with a 5 µm core margin (core from 5 µm to 90 µm). That is the smallest 5 µm step that still finishes detailed route for this netlist, landing near 66% utilization. A 90×90 µm attempt fails detailed route (on the order of sixteen violations in the verified teaching runs). Barely routing is the point: you learn where the cliff is.

In DEF units with UNITS DISTANCE MICRONS 1000, that teaching outline is:

DIEAREA ( 0 0 ) ( 95000 95000 ) ;

---

Why PDN matters

A power distribution network (PDN) is the on-die wiring that delivers supply and ground to every standard cell. In everyday terms: without rails, straps, and usually a ring, the placer can still park cells in rows, but the router has no legal path to feed VPWR and VGND (the sky130 HD names). Detailed route then fails, times out, or produces fragile results that look “almost done” in a GUI.

The teaching sketch below names three ideas you will see in the Tcl: a ring around the core, vertical straps on upper metals, and horizontal rails that follow the standard-cell rows. Part 4 builds a functional minimum with met4/met5 straps connected down to met1 follow-pin rails—enough for route to complete on the 95 µm die. It is not a foundry signoff PDN for a shuttle tapeout.

Place-only is therefore not enough. The size decision for the die must survive PDN plus route, not merely a legalized placement screenshot.

---

After place / after route — what the GUI shows

OpenROAD’s GUI (or a save_image capture) is still useful for teaching stages, as long as you remember the deliverable is the DEF file. The next two figures show real OpenROAD views on an oversized die used as a stage contrast: first after placement with tap and filler, then after PDN and detailed route when signal wires and vias appear.

Read them as stage pictures (place, then route), and read the 200 µm and 95 µm figures above as size pictures (too large versus barely OK). A dense screenshot is evidence that metal exists; it is not a substitute for checking DESIGN, UNITS, and DIEAREA in the DEF header.

---

Workflow: environment, Makefile, and the Tcl run

Work inside the unpacked quad-encoder-i2c-openroad folder. Set the PDK, then run OpenROAD:

export PDK_ROOT=/path/to/your/pdk/root
export PDK=sky130A
make openroad

Equivalently:

make or
# or without make:
openroad -exit openroad/run_minimal.tcl

Optional overrides for experiments (teaching default is already 95 / 5):

DIE_UM=95 MARGIN_UM=5 make openroad

The script openroad/run_minimal.tcl resolves TechLEF, cell LEF, and Liberty from PDK_ROOT/PDK (or from TECH_LEF/CELL_LEF/LIBERTY), reads synth/encoder_top_gl.v, links encoder_top, builds the floorplan, places at density 0.7, inserts tap and filler, generates the PDN (pitches snapped to a 0.005 µm grid), runs global route with congestion allowed, runs detailed route for up to forty end iterations, and writes the DEF. On a verified 95×95 µm teaching run the console ends near the lines below; your log may differ slightly by tool version.

You should see a design-area line on the order of:

Design area  4736 u^2  66% utilization.

and a write of openroad/out/encoder_top.def.

---

Check the DEF header

Before you celebrate the screenshot, open the DEF and read the header:

head -n 20 openroad/out/encoder_top.def

Confirm at least:

DESIGN encoder_top ;
UNITS DISTANCE MICRONS 1000 ;
DIEAREA ( 0 0 ) ( 95000 95000 ) ;

DESIGN must match the Yosys top. UNITS … 1000 means one micron is one thousand database units, so 95000 is 95 µm. Then skim for ROW … unithd lines and a non-empty COMPONENTS section. After a routed run you should also see NETS / SPECIALNETS content for signal and power. If the header is wrong, Part 5 cannot fix it by importing harder—regenerate the DEF.

---

Pitfalls

A few failure modes show up again and again when beginners first touch OpenROAD:

Too-small die without iteration. A 90 µm outline that dies in detailed route is a teaching tool, not a personal failure. Enlarge by 5 µm or revisit fill; do not silently jump back to 200 µm “so it works.”

Place without PDN. Legalization can succeed while detailed route never finishes. Part 4 includes pdngen for that reason.

Pins before tracks, or wrong pin layers. Call make_tracks immediately after initialize_floorplan. For sky130 HD, place_pins -hor_layers met3 -ver_layers met2 matches the preferred directions in the TechLEF. Skipping tracks reproduces classic pin-placer errors.

Hardcoded PDK paths. Absolute paths from another machine break on yours. Use PDK_ROOT or explicit TECH_LEF/CELL_LEF/LIBERTY env vars.

Screenshot as deliverable. Part 5 needs DEF bytes. A PNG proves you saw metal; it does not give LayoutEditor rows and components to import.

Wrong top name. link_design encoder_top must match the Yosys top exactly.

---

Zip contents reminder

Inside quad-encoder-i2c-openroad you should find:

• synth/encoder_top_gl.v — Part 3 gate-level netlist
• openroad/run_minimal.tcl — floorplan → place → PDN → route → write_def
• Makefile — make openroad / make or
• README.md — reader-facing setup notes
• openroad/out/ — created on run; encoder_top.def lands here

That is the whole Part 4 package. Keep it beside the Part 3 zip if you want both simulation and physical-design trees on disk; Part 4 does not re-run Yosys.

---

Outlook

Part 5 continues with DEF→GDS and DRC in LayoutEditor.