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

Flow A is written so the PDK is a set of file paths and cell names read from $PDK_ROOT/$PDK, not hardcoded logic — but several Sky130-specific names (site name, corner name, buffer names) do appear directly in the scripts and need updating for a new PDK. This page is the checklist 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.

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¶

initialize_floorplan -site <SITE> in pnr.tcl 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¶

insert_tiecells <cell>/LO and <cell>/HI in pnr.tcl 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¶

clock_tree_synthesis -root_buf ... -buf_list {...} names 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¶

set_routing_layers -signal <range> -clock <range> and the -hor_layers/-ver_layers arguments to 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¶

extract_parasitics -ext_model_file ... 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 — note the file itself is tool-agnostic despite living under a LibreLane-branded directory; that’s just the PDK package’s own naming). Locate the equivalent rules file for the new PDK, usually shipped alongside its other libs.tech/ tool-integration directories.

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. 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¶

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).
Update items 2–8 above in synth.tcl, ppa_report.tcl, and pnr.tcl for 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.
Re-derive the clock period (item 9) rather than reusing the old number.
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.
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.