================================================= 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 (:doc:`flow-a-overview`). * The ``.core`` file structure, testbench conventions, and manual gate-level simulation commands (:doc:`running-your-own-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 -------------------------------------------------- .. code-block:: sh export PDK_ROOT="" export PDK="" If the new PDK is managed by ``ciel`` (any ``open_pdks``-built PDK), use ``ciel ls-remote``/``ciel enable`` as in :doc:`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 ```` placeholder in :doc:`running-your-own-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//``: .. list-table:: :header-rows: 1 * - File - Used by * - ``verilog/.v`` (+ ``primitives.v`` if separate) - Gate-level simulation (Icarus) * - ``lib/.lib`` (Liberty) - ``dfflibmap``/``abc`` (Yosys), OpenSTA timing/power * - ``lef/.lef`` - OpenROAD placement/routing (abstract cell views) * - ``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//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 `` in ``pnr.tcl`` must match the ``SITE`` block defined in the new PDK's technology LEF, e.g.: .. code-block:: text SITE SYMMETRY Y ; CLASS CORE ; SIZE BY ; END 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 /LO`` and ``/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 -clock `` 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/.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 :doc:`running-your-own-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. .. _Finding a target clock period: running-your-own-design.html#finding-a-target-clock-period 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 ===================================== 1. Get the new PDK installed and confirm ``$PDK_ROOT/$PDK`` resolves, following the same per-tool verification steps as :doc:`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. 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. 3. Re-derive the clock period (item 9) rather than reusing the old number. 4. Run the full pipeline from :doc:`running-your-own-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.