PDK Portability (e.g. Retargeting to 55 nm)

Flow A keeps every PDK-specific value — file paths, site name, corner, tie/tap/clock-buffer cells, routing layers, the power grid — in one technology file, scripts/tech/<TECH>.tcl (sky130hd.tcl is the provided one; TECH selects it, default sky130hd). No flow script (synth.tcl, ppa_report.tcl, pnr.tcl, power_activity*.tcl, gen_gds.sh, the Makefile) names a PDK, so retargeting means writing one new file, not editing the scripts. This page is the checklist for that file — for swapping in a different PDK — for example, a closed 55 nm node for Flow B, or any other open or closed standard-cell library — without changing anything about how the flow itself works.

Nothing on this page is specific to swapping in a closed PDK, either: the same checklist applies to swapping between two open PDKs.

How to add a technology

cp scripts/tech/TEMPLATE.tcl scripts/tech/<name>.tcl   # fill in every value
export TECH=<name>
make tech-check                                        # lists anything missing
# equivalent: tclsh scripts/tech_query.tcl check

The numbered items below say what each variable in that file means and where to find its value in the new PDK.

Signoff-related tech variables

Beyond the library, extraction and PnR values, the tech file also supplies what pnr.tcl and the signoff scripts need (see scripts/tech/TEMPLATE.tcl): tech_wire_rc (proc, wire RC layers for repair and CTS), dont_use_cells (glob patterns excluded from synthesis and resizing), cell_cdl and cell_spice (standard-cell CDL for write_cdl and SPICE for the LVS schematic), tie_cell and tie_pins (which rail each tie output equals in the layout), fill_cells (largest first), diode_cell (antenna diode), and klayout_drc / klayout_lvs (signoff decks). A closed PDK usually has its own DRC/LVS decks (for example Calibre in Flows C/D); in that case drc.sh and lvs.sh are replaced by the vendor flow, and only the netlist and GDS handoff stays the same.

What stays the same

• The pipeline structure and stage order (Flow A: Overview).

• The .core file structure, testbench conventions, and manual gate-level simulation commands (Running Flow A on Your Own SV Design).

• The general shape of every Tcl script (synth.tcl, ppa_report.tcl, pnr.tcl) — you are editing values inside them, not restructuring them.

What must change

1. PDK_ROOT / PDK environment variables

export PDK_ROOT="<path to the new PDK's root>"
export PDK="<new PDK/variant name>"

If the new PDK is managed by ciel (any open_pdks-built PDK), use ciel ls-remote/ciel enable as in Getting Started. If it’s a licensed/closed PDK, it will typically come from your foundry or a PDK vendor package instead — follow their install instructions, but still expose it under a consistent $PDK_ROOT/$PDK pair so the rest of the flow doesn’t need to change.

2. Standard-cell library path and naming

Every <STD_CELL_LIB> placeholder in Running Flow A on Your Own SV Design (e.g. Sky130’s sky130_fd_sc_hd) becomes whatever your new PDK’s standard-cell library directory/prefix is named. Locate the equivalent of each of these under the new $PDK_ROOT/$PDK/libs.ref/<STD_CELL_LIB>/:

File	Used by
verilog/<STD_CELL_LIB>.v (+ primitives.v if separate)	Gate-level simulation (Icarus)
lib/<CORNER>.lib (Liberty)	dfflibmap/abc (Yosys), OpenSTA timing/power
lef/<STD_CELL_LIB>.lef	OpenROAD placement/routing (abstract cell views)
techlef/<TECHLEF>.tlef	OpenROAD floorplanning (layers, vias, site definition)

3. Corner name

The Liberty file’s corner label (Sky130’s example: tt_025C_1v80, i.e. typical process, 25 °C, 1.8 V) is PDK-specific. Check what corners your new PDK ships (ls $PDK_ROOT/$PDK/libs.ref/<STD_CELL_LIB>/lib/) and pick the one matching the analysis you want (typically “typical” for functional/nominal PPA work, plus separate best/worst-case corners if you need setup/hold sign-off across corners — out of scope for the base flow described here).

4. Standard-cell site name

fp_site in the technology file (used by initialize_floorplan -site) must match the SITE block defined in the new PDK’s technology LEF, e.g.:

SITE <site_name>
  SYMMETRY Y ;
  CLASS CORE ;
  SIZE <width> BY <height> ;
END <site_name>

Grep the new tech LEF for SITE to find the right name and confirm the row height makes sense for your target density.

5. Tie cells

tie_lo / tie_hi (used by insert_tiecells) are <cell>/<pin> and reference PDK-specific tie-high/tie-low cell names (Sky130 HD’s example: sky130_fd_sc_hd__conb_1). Find the equivalent constant-driver cells in the new library (commonly named conb, tieh/tiel, or similar) and check their pin names for HI/LO.

6. CTS buffer list

cts_root_buf / cts_buf_list (used by clock_tree_synthesis) name specific clock buffer cells from the standard-cell library (Sky130 HD’s example uses its clkbuf_2/clkbuf_4/clkbuf_8 family). Substitute the new library’s clock buffer cells, generally choosing a small spread of drive strengths so CTS has options for different fanout/skew targets.

7. Routing layers

route_layers_signal / route_layers_clock (set_routing_layers) and pin_hor_layers / pin_ver_layers (place_pins) reference metal layer names (Sky130 HD’s example: signal on met1–met5, clock restricted to met3–met5, pins on met2/met3). Check the new PDK’s metal stack (how many routing layers it defines, and any platform convention for reserving upper layers for clock/power) and pick an equivalent split.

8. Parasitic extraction rules file

rcx_rules (used by set_extraction_rules_file before extract_parasitics) points at an OpenRCX rules file specific to the PDK’s process corner (Sky130’s example: libs.tech/librelane/rules.openrcx.sky130A.nom.spef_extractor — a plain OpenRCX file; the directory name is only how open_pdks packages it, and no LibreLane tool is involved). Locate the equivalent rules file for the new PDK, usually shipped alongside its other libs.tech/ tool-integration directories.

If the PDK ships separate rules files per RC corner (Sky130 has nom, min and max), also define rcx_rules_by_corner in the tech file (dict create nom <file> min <file> max <file>). pnr.tcl then extracts once per entry and writes <design>_route.spef (nom) and <design>_route_<corner>.spef; multicorner.tcl uses max for ss* corners and min for ff* corners. Without the dict, the flow extracts the single rcx_rules file only. Check what the corner files actually change: for Sky130 they differ in resistance only, not capacitance.

9. Timing constraints (SDC) and clock period

Every number in constraints/<design>.sdc and in ppa_report.tcl — clock period, clock uncertainty, input/output delay budgets, output load — is derived relative to the old PDK’s timing characteristics and should not be carried over as-is. Re-run the Finding a target clock period sweep described in Running Flow A on Your Own SV Design against the new library’s Liberty file to find a new, meaningful operating point; a period tuned for a 130 nm library has no particular relationship to what’s achievable on a 55 nm (or any other) node.

10. Tap cells and power grid

tech_tapcell and tech_pdn are procs in the technology file that pnr.tcl calls inside the OpenROAD session (tap-cell master/pitch; global connections, rings/stripes and pdngen). They are the only PDK-specific commands rather than values, so they live in the same file; write them for the new PDK’s metal stack.

11. KLayout technology file (viewing only)

If you plan to view GDS output in KLayout, the new PDK should ship a libs.tech/klayout/ technology directory (layer definitions, DRC decks) analogous to Sky130’s. Point KLayout at it via File → Setup → Technologies, or check the PDK’s own documentation for a KLayout .lyt/.lyp file to load. This step only affects layout viewing/editing, not the OpenROAD/Yosys pipeline itself.

Suggested workflow for a retarget

1. Get the new PDK installed and confirm $PDK_ROOT/$PDK resolves, following the same per-tool verification steps as Getting Started (Yosys can load the standard-cell Verilog, OpenROAD can read the tech + cell LEF, KLayout starts and can load the tech file).

2. Fill in items 2–8 above in the new scripts/tech/<name>.tcl (the flow scripts themselves stay untouched) and run it on one already-known-working design (e.g. re-run the myfir reference design against the new PDK) — this isolates PDK issues from design issues, since the RTL/testbench are already proven correct on the original PDK.

3. Re-derive the clock period (item 9) rather than reusing the old number.

4. Run the full pipeline from Running Flow A on Your Own SV Design end-to-end and confirm bit-exact functional results at every stage before trusting any PPA numbers from the new PDK.

5. Only then move real designs over to the new PDK target.

Closed/licensed PDKs specifically

If the new PDK is under an NDA or license restricting redistribution (e.g. a foundry 55 nm PDK for Flow B/D), keep its files and any PDK-derived data (LEF/Liberty excerpts, extracted PPA numbers depending on your NDA terms) out of version control, consistent with how this repository already excludes closed-PDK data — see the top-level README.md for the current policy. Everything on this page still applies to how the scripts reference the PDK; only where the PDK files themselves are allowed to live changes.