vyges-pdn — the power distribution network

Physical construction — opt-in, and not part of vyges install loom. These engines build the design database that the sign-off and verification engines read, so they install as their own group:

vyges install physical   # all six
vyges install pdn        # just this one

It is also a standalone vyges-pdn binary on your PATH, which is what the dispatch calls and what a flow author targets directly. Source: vyges-tools/pdn.

vyges-pdn builds the metal that carries power across the die: rings around the core, straps on a pitch across it, follow pins along every standard-cell row, and the vias that stitch the layers together. It is the largest engine in the construction group and the one with the most geometry to get exactly right.

Run it

vyges pdn generate design.odb --out-def pdn.def --power VDD --ground VSS \
  --followpins metal1 \
  --stripe metal4:1.6:56.0:2.0 \
  --ring metal5,metal6:2.0:2.0:2.0

Each --stripe, --ring and --followpins may repeat; --grid partitions the options into several grids, as a design with macros needs.

Where it sits

Floorplanned and tapped database in, power geometry out — as a DEF, or written back into the database. Everything that later analyses power integrity (em-ir) reads what this produced.

Verdicts that are not verdicts

status is generated, vacuous or error. vacuous is not a pass: it means the run laid no metal at all, which usually means an option did not arrive rather than that the design needed nothing. The declared assertion passes only on generated.

Known bounds

• Argument validation, connect rules and the runtime checks are implemented as diagnostics with the reference’s own message codes; other codes are reported as unimplemented rather than silently skipped.

See the full CLI reference (generated from --help and --describe).