Vyges Loom · Physical construction
Cut the rows around macros, and place the physical cells that keep them legal.
Well taps and endcaps — matched to position, orientation and master, because a wrong endcap is a well-tie fault nobody sees until silicon.
Used by: anyone with a macro in their floorplan, or a process that requires well taps at a maximum spacing.
Rows cannot run through a placed macro, and a row that simply stops needs its ends capped. Meanwhile the wells under the standard cells have to be tied to supply at a spacing the process dictates. Both are invisible in simulation and both are silicon failures when wrong.
vyges-tap does three things: cuts rows around blockages with a halo, places endcaps at the row ends and corners, and distributes well taps at the required pitch. It can also rip them all back out.
.odb with macros ──► vyges-tap ──► cut rows + taps + endcaps (master, position, orientation)
Endcap positions can be filled from the library’s own LEF58 master types rather than named one by one. When two masters both claim the same position, this fails and names both instead of picking one.
That is a deliberate choice about failure modes. A wrong endcap is a well-tie fault — it passes every check you run, and it shows up in silicon. A tool that quietly picks one has converted a question you could have answered into a defect you cannot see.
A position that nothing fills stays empty and places nothing. Taps and endcaps also carry different name prefixes (TAP_ and PHY_) because they are separate namespaces you can rip up independently — and an empty rip-up prefix removes nothing rather than everything, which is the difference between undoing a step and destroying the design.
Blockages are placed macros. A macro that is not placed yet is skipped — and reported by name, because rows cut for a location nothing occupies are worse than rows not cut at all.
The minimum row width is the larger of two endcap widths and whatever floor you pass, so your own argument cannot quietly produce rows too narrow to cap.
A run that changed nothing reports vacuous, never applied — a no-op fails the assertion rather than reporting a transformation that did not happen.
Status is one of applied · planned (dry run) · vacuous · error — and the declared assertion passes only on applied.
After vyges-ifp has built the rows and the macros are placed; before the power grid runs its follow pins along whatever rows survive the cut. Reads and writes the shared database through vyges-opendb.
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 →