A manifest for every PDK — one uniform descriptor that presents any process design kit to the tools that consume it — any node, from advanced 2 nm to mature 130/180 nm and beyond.
TL;DR: a single JSON manifest that lets tools consume any PDK the same way — without reworking flows.
At Vyges, we build silicon like software. With VyCatalog, verified silicon IPs drop straight into the workflow, and every artifact a quality chip needs (RTL, firmware, tests, constraints, hardening) is generated from metadata, not hand-assembled. In our internal work this collapses composing an SoC, verifying it, and bringing it up on both FPGA and ASIC from many months to days or weeks. When iteration is that fast, a new question opens up:
What if you built the same design against a different PDK?
A smaller die. A tighter power budget. A cheaper or more available node. A more mature process for better yield. Sweeping several PDKs for die size, cost, node availability, or yield was almost impossible in the past — too slow to be worth it — so designs were locked to one process early and rarely revisited. At software speed it becomes just another axis to explore. When the flow is software, retargeting should be a flag — not a project. But every PDK is laid out differently: heterogeneous collateral, paths, corners, and cell libraries. Swapping by hand is slow and error-prone — the opposite of "like software."
So we built the missing piece: one uniform way to present any PDK to the flow. One descriptor per PDK; swap with --pdk sky130 or --pdk gf180mcu; the generator and the sign-off engines do the rest. And the PDK Descriptor Standard was born.
A PDK descriptor (*.vyges-pdk.json) maps a PDK's heterogeneous on-disk layout onto a uniform set of collateral keys. A flow resolves --pdk <name> + a corner (+ a cell library) to concrete file paths — regardless of node, foundry, layout, or hosting.
It is a presentation contract on top of existing PDK hosting — Ciel (the open-PDK distribution manager used for sky130 / gf180), mirrors, and private object stores — it does not host, index, or re-implement that infrastructure. The descriptor is data; engines stay path-based; the pdk-store resolver that reads it is downstream.
One descriptor in — every tool resolves the PDK the same way.
Pull & build
Grab a built PDK from pdk-releases — ciel-compatible, per-library tarballs — and start. No spelunking through directory layouts.
One resolve, every tool
pdk-store turns --pdk <name> + a corner into real collateral paths. All six Loom sign-off engines — and the optimizers — read the same map. Zero per-tool wiring.
Retarget with a flag
It maps collateral categories, not contents — so the same keys hold from 2 nm to 180 nm. Swapping PDKs is a flag, not a project.
A presentation layer over your existing PDK hosting — it never moves, renames, or redefines a single file. OpenLane and LibreLane keep their native resolution; everything else gets one uniform map.
One map per PDK. Schema-checked, CI-tested, versioned — the same shape for every node.
A PDK descriptor is the "nutrition label" / package.json for a PDK — a small, vendor-neutral manifest a foundry ships alongside its PDK so any tool (open or commercial) can consume the PDK uniformly without bespoke per-tool wiring.
Any tool can consume the descriptor directly — the Vyges Loom engines are simply the first adopters. We're publishing this openly to enable discussion, adoption, and iteration — not to gate or centralize control.
JSON Schema 2020-12 · 21 top-level fields · 6 required
https://vyges.com/schema/v1/vyges-pdk.schema.json