Vyges Loom · Physical construction

vyges-pad

Lay the IO ring around the die, and place what sits in it.

Corners sized from the corner site, edges truncated to whole sites — with legality checked layer by layer, not by bounding box.

View source on GitHub →

What it does

Used by: anyone taking a block to a package — the ring is the boundary between your design and the outside world.

The IO ring is the band of rows around the die that pads, corners and bumps are placed into. Its geometry is unforgiving: the ring is the die inset by an offset, its corners sized from the corner site, and its four edges truncated to whole sites — a remainder that does not fill a site is given up rather than rounded out.

vyges-pad builds that ring and places pads and corners into it, with row orientation resolved the way the rest of the industry resolves it: left and right rows lie on their side when the horizontal and vertical sites are the same site, and stand upright when they differ.

.odb + site names + offset  ──►  vyges-pad  ──►  IO rows (name, site, origin, orientation, pitch), placed pads and corners

Legality is a layer question, not a rectangle question

A cell is refused a position by a layer-aware check. A fixed instance blocks by its box, refined by its overlap-layer outline where either side declares one; anything sharing a layer blocks when the moving cell’s shapes, grown by that layer’s spacing, reach it.

The consequence that matters: a bump never blocks by box — only by shared metal. A bounding-box check would reject perfectly legal placements underneath one, and you would spend the afternoon working out why.

A corner’s width is the larger of the corner site’s width and the horizontal row’s depth — so the row abutting a corner can be what sets its size.

The ring is what everything else is measured from

Every pad, corner and bump position is relative to the ring, so a ring that is off by one site is not one bug — it is every placement after it, all slightly wrong, none obviously so. It is the cheapest thing on this page to get right and the most expensive to get wrong.

Which is why the ring is exact on real sky130 designs down to name, site, origin, orientation, direction, site count and pitch — and why a cell that cannot legally go where you asked is refused and named rather than nudged somewhere plausible.

One simplification, stated: shape nets are not carried, so two shapes on the same net read as a conflict rather than being allowed to touch. A cell being created has no nets, which is why the supported cases are unaffected — but a command placing already-connected cells would need it.

Try it

$ vyges install physical   # one-time: fetch the construction engines into ~/.vyges/bin
$ vyges physical pad make-io-sites design.odb --horizontal-site IOSITE \
    --vertical-site IOSITE --corner-site CORNER --offset 0   # build the ring
$ vyges physical pad place-corners design.odb --master CORNER_PAD   # place the four corners
$ vyges physical pad place-pad design.odb --row IO_EAST --location 120 \
    --master PAD_GPIO --inst u_pad_0   # place one pad

Reports the ring and every placement as JSON, and exits non-zero when a cell cannot legally go where it was asked to go.

Where it sits in the flow

Around everything else. The ring is built on the die that vyges-ifp established, and the pins that vyges-ppl places on the boundary are what the pads ultimately connect the design to.

Beyond the ring, the same binary handles bond pads, bump arrays, IO fill, terminals, connection by abutment and RDL routing — connecting bumps to pads across the face of the die on one thick layer. Those are built and tested; what the measured claim above covers is the ring and pad/corner placement, which are the parts with reference cases behind them. Implemented and correlated are not the same word, and this page keeps them apart.

Open core · Apache-2.0

A clean-room Rust engine writing the shared design database through vyges-opendb, so the block you check is the block you built. See all the engines & the data spine →