Vyges Loom · Physical construction
Put the macros where the block can be built around them.
Explicit placement at the coordinates your config states, and hierarchical placement that clusters, shapes and anneals — writing locations and orientations straight into the design database.
Used by: anyone hardening a block with SRAMs, register files or hard IP — where the macros sit decides the shape of everything placed after them.
Macros are the immovable furniture of a block. Once they are down, they define the channels the standard cells live in, the paths the power straps take, and the wire length every net after them has to pay. Put them badly and no amount of downstream effort recovers it.
vyges-mpl offers both routes. Explicit placement takes the coordinates and orientations your configuration already states and commits them, each macro left fixed. Hierarchical placement derives them: it clusters the netlist through multiple levels, shapes each cluster coarsely, anneals the arrangement, pushes macros to the core boundaries, and commits the result.
.odb + macro coordinates or a netlist to cluster ──► vyges-mpl ──► macro locations, orientations, placement blockages
A design whose macros are all already fixed gives this engine nothing to do. It reports vacuous — its own exit status, distinct from success — rather than returning zero over a database it never touched.
That distinction matters most in the place it is easiest to lose: a flow step that silently no-ops looks identical to one that worked, and the difference only surfaces much later, in a result nobody can explain. A pass word should never come from a run that did nothing.
Coordinates are the macro origin in microns, the same convention your configuration states them in — not a centre, and not database units unless you ask for them.
Scope, stated plainly: this engine does not implement hypergraph partitioning. A flat cluster — one with no module children — whose leaf standard cells exceed the level threshold is refused, not approximated. A synthesised block that has been fully flattened reaches that path; a hierarchical one generally does not.
Refusing is the useful behaviour. An approximation here would produce a placement that looks finished, costs nothing to accept, and is wrong in a way no downstream check reports as a macro-placement problem. A named refusal is a fact you can act on.
Explicit placement has no such limit and is the path a real harden flow uses today — it is what the taped-out blocks in our own SoC were built with.
Exit status is the verdict: 0 applied · 1 refused · 2 error · 3 vacuous (no unfixed macros) — so CI gates on the exit code without parsing prose.
After vyges-ifp has built the rows, and before vyges-tap cuts them — because tap cuts rows around macros, and it can only do that once the macros have somewhere to be. vyges-pdn then routes the grid around what is there.
It writes in place over the input database — the locations and orientations are the result, so there is no report file to carry between steps and nothing to keep in sync.
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 →