Vyges™ Loom

Commercial-grade engines for EDA sign-off — the optimizers that close the loop, and the checks that prove it.

The engines weave on the loom; VyBox Sley drives the weave.

driven by declarative job files over one cross-engine data spine.

TL;DR: the sign-off math — and the timing/leakage fixes — you used to pay a vendor for. Open, scriptable, CI-native. Apache-2.0.

The deterministic execution layer behind AI-native silicon design — the engines that turn AI reasoning into real chip implementation, on your hardware.

The Loom suite: external inputs (.ext, .char, .vcd/.saif, .gds/.oas + rules, .v/.json netlist, .sdc) enter; a Sign-off · analyze group (extract, char, power, sta-si, em-ir, thermal, lvs), an Optimizers · act group (resize, vt-swap, buffer-insert, hold-fix), and a Verification · prove / view group (drc, cdc, glitch, lec, gds-view) compose over shared artifacts (.spef, .lib, activity) and one timing graph; results (WNS/TNS, IR-drop/EM, temp/hotspot, MATCH/MISMATCH, fixed netlist, DRC violations, CDC/glitch/LEC verdicts, layout SVG) come out. A dashed loop shows the incremental cone-localized timing update. The engines validated for analog and mixed-signal (extract, em-ir, thermal, lvs, and the geometry engines drc and gds-view) carry a double border; .gds + rules also feeds extract directly via its gds-to-net adapter.

Hover to zoom · click to open the full-size diagram

Built for silicon teams doing real sign-off — startups without seven-figure EDA budgets, platform teams standardizing CI flows, and foundries enabling reproducible PDK validation.

Why now? Proprietary sign-off tools were built for monolithic flows — not CI, not reproducibility, and not open ecosystems.

Every engine, one spine

A software architecture, not an EDA bundle. Each engine takes a declarative job file and produces a standard artifact, and they share a cross-engine data spine — the output of one is the input of the next, with no glue scripts and no silent copy-drift.

Sign-off · analyze

They say what's wrong — and gate CI on it.

Parallel model compiler

vyges-char

Generates Liberty (.lib) timing & power models from SPICE — parallel-SPICE orchestration over a declarative .char job. The OSS community's missing parallel characterizer.

Physical-truth extractor

vyges-extract

Extracts interconnect RC parasitics → SPEF from a layout, driven by a declarative .ext job. Feeds the timing and power solves downstream. Works on analog & mixed-signal layouts too — RC is geometry, not cell-specific.

Timing decision function

vyges-sta-si

Static timing analysis with signal integrity → WNS / TNS and the worst path. Reads the .lib + .spef from the two engines above; gates CI with a distinct violation exit code.

Power-budget enforcer

vyges-em-ir

Solves the power-distribution network (PDN) → IR-drop + electromigration (EM) against a budget, driven by a declarative .emir job. Digital, analog & mixed-signal grids alike — it's grid physics, not a standard-cell construct.

Activity & power solver

vyges-power

Computes leakage + internal + switching power from netlist, .lib and activity — and emits the per-instance activity map em-ir needs. Closes char → power → em-ir.

Hotspot & temperature

vyges-thermal

Lands the same power map on the die as heat → peak temperature + the hotspot, with electro-thermal coupling (leakage ⇄ temperature). The thermal dual of em-ir; closes power → thermal → power. Analog & mixed-signal blocks too — heat flow is technology-agnostic.

Layout-correctness checker

vyges-lvs

Does the layout implement the schematic? A name-independent graph match → MATCH / MISMATCH with the divergence named — plus native GDS / OASIS extraction. Correlated exact vs Magic. Digital, analog & mixed-signal netlists alike — the device-graph compare is technology-agnostic.

Digital and analog / mixed-signal. Four of these — extract, em-ir, thermal, lvs — extend to analog & mixed-signal physical & integrity verification (connectivity, RC, IR/EM, thermal). Functional/timing sign-off stays digital.

Optimizers · act

The analysis says what's wrong; these fix it — netlist in, better netlist out, every move scored by the same sta-si timer. Same footprint (resize, vt-swap), or add cells (buffer-insert for transition, hold-fix for post-route hold); placement stays the flow's job.

Gate sizing

vyges-resize

Picks a better drive strength per cell — upsize the critical path to close setup, downsize slack for area. Pre-place or post-place ECO with SPEF.

Leakage / speed trade

vyges-vt-swap

Trades threshold voltage (iso-footprint): push slack cells to high-Vt to cut leakage while timing holds, or low-Vt to close setup.

Transition fixup

vyges-buffer-insert

Splits a heavily-loaded net — a buffer takes over a share of the sinks so the driver's transition drops back under the limit, timing still met.

Post-route hold

vyges-hold-fix

Inserts series delay on hold-violating capture pins — the hold counterpart to the setup-side optimizers, scored against real routed parasitics.

Verification · prove / view

Beyond timing and power: prove the layout is legal, the clock domains are safe, the logic didn't change — and see exactly where. The structural and formal checks that catch what simulation can't, on the same spine.

Geometry-rule enforcer

vyges-drc

Does the layout obey the foundry's rules? Checks width, spacing, area, density, antenna and enclosure on a GDS or OASIS layout — and generates metal fill to hit a density target. The geometric sibling of lvs. Analog & mixed-signal too — geometry is technology-agnostic.

Clock-domain guard

vyges-cdc

Catches the metastability bug simulation can't see: a signal crossing between unrelated clocks with no synchronizer. Netlist + clocks in, the unsafe crossings named out.

Glitch / hazard finder

vyges-glitch

Finds where a signal can momentarily glitch before it settles — the reconvergent-fanout hazard a cycle-based simulator steps right over. Static and dynamic, from the same timing data sta-si uses.

Equivalence prover

vyges-lec

Did that synthesis, ECO or hand-edit keep the logic the same? Proves two netlists compute the same function across all inputs — or hands you the one input where they differ. The formal complement to simulation.

Layout viewer

vyges-gds-view

Renders a GDS or OASIS layout to a layered SVG, headless — and overlays exactly where DRC or LVS flagged a problem. The where to the what, in any browser, no GUI to install.

Underneath · the geometry kernel

vyges-layout — the clean-room Rust geometry kernel the layout-side tools ride on: it reads both GDSII and OASIS (the compact modern format, compressed or not) and does the boolean / flatten the engines need — so vyges-lvs, drc and gds-view take a layout in either format, no external converter. A foundation library, not a sign-off engine — it emits geometry, not a verdict — so it sits beneath the engines rather than among them.

vyges-loom — the cross-engine data spine

.ext ─► extract ─► .spef ──┐
.char ─► char ─► .lib ─────┼─► sta-si ─► WNS/TNS
                           └─► power ─► activity ─┬─► em-ir ─► IR/EM
                                                  └─► thermal ─► temp/hotspot
.gds/.oas + rules ─► lvs ─► MATCH / MISMATCH   ·   drc ─► DRC violations   ·   gds-view ─► layout SVG
.v/.json + .lib + .sdc ─► cdc · glitch · lec ─► crossings · hazards · EQUIVALENT? (+ counter-example)

One declarative job file per run; one standard artifact out; the next engine reads it directly — every engine shares the vyges-loom spine, so there are no glue scripts and no silent copy-drift. The same files a foundry's sign-off team expects (Liberty, SPEF) — produced by an open, scriptable, CI-native flow instead of a black box.

It's real software

$ vyges install loom
# fetch the Loom suite on demand — prebuilt from its public release into ~/.vyges/bin
$ vyges loom char demo  ·  vyges loom extract demo  ·  vyges loom sta-si demo  ·  vyges loom em-ir demo  ·  vyges loom power demo  ·  vyges loom thermal demo  ·  vyges loom lvs demo
$ vyges loom resize demo  ·  vyges loom vt-swap demo  ·  vyges loom buffer-insert demo  ·  vyges loom hold-fix demo  ·  vyges loom drc demo  ·  vyges loom gds-view demo
# a zero-setup demo per analyze / optimize engine — built-in example, no inputs · the structural checkers (cdc, glitch, lec) run on a netlist — see each engine page

Standard Liberty / SPEF outputs drop straight into existing sign-off flows, and the engines are CI-exercised on the open PDKs (sky130, gf180) — that's what "commercial-grade" means here.

New · AI optional · runs on your hardware

Three ways to drive Loom — AI is optional

A model reasons; Vyges executes. Reach the same engines three ways — from the CLI & CI, from your AI IDE, or by registering a model and letting vyges drive it. Bring any AI model — general-purpose (Claude, GPT, Grok), open-weight (Qwen, Llama, DeepSeek), or a semiconductor-specific model such as SemiKong. If it can call tools, it can drive Loom through vyges mcp. It all runs on your hardware — no cloud, no upload, no auth.

1 · CLI & CI

No AI at all

vyges loom drc run … — scriptable, CI-native, reproducible. The deterministic core stands on its own.

2 · AI IDE — bring your model

Claude Code · Cursor · VS Code

Point any MCP client at vyges mcp; your assistant calls the engines as tools. You bring the model, Vyges brings the tools.

3 · vyges model run — autonomous

Register a model; Vyges drives it

Register a local model with vyges model; vyges model run runs the reason → act → observe loop itself — for CI, air-gapped, and autonomous flows.

Every engineer already knows how to use Claude or Cursor. Now those same assistants can drive real silicon implementation tools.

Already using SemiKong?

Keep your model. Register it with vyges model, point it at vyges mcp, and it can drive DRC, LVS, timing, extraction, and optimization against your own PDK and private IP — entirely on local hardware.

$ vyges install loom
$ vyges mcp setup  # register Loom with the AI IDEs on your machine
# then, in your IDE: "run DRC on this GDS against the sky130 deck installed locally"

Deterministic execution

The AI is a driver, never inside the engines. Pull it out and the exact same flow runs headless in CI — reproducible, the way a tapeout demands.

Your design never leaves your box

A plain local subprocess over stdio — no server, no port, no auth. The right trust model for RTL, layout, and PDKs under NDA.

loom.feedback — the agent's eyes

One call returns a rendered layout, categorized DRC verdicts, and a score — so an agent can debug a layout, not just pass/fail it.

Walkthrough: Point your AI IDE at your own silicon tools →

Already on OpenLane / LibreLane? Drop these in.

These are sign-off engines, not another flow — single std-only binaries, seconds not stages, no nix store and no 60-stage orchestration to sanity-check timing. You keep running LibreLane for place-and-route; you just enter it cleaner and verify its output with a faster, more legible checker.

Right after Yosys (pre-P&R) — shift the gate left

Catch a broken constraint, a timing wall, a power problem — or a clock-domain crossing, a glitch, a logic change an ECO slipped in — before you spend an hour in P&R, so you re-spin the heavy flow fewer times.

EngineRuns onCatches early
sta-sisynth netlist + .lib + SDCbroken constraints, a timing wall, bad clock setup
powersynth netlist + .lib + VCD/vectorlessa power / activity problem while it's still cheap to fix
cdcsynth netlist + .lib + SDCan unsynchronized clock-domain crossing — before it's a silicon-only metastability bug
glitchsynth netlist + .liba reconvergent-fanout glitch on an async / latch / clock-gate path
lectwo netlists + .liba synthesis re-run or hand-ECO that silently changed the logic

After the flow produces layout — independent fast sign-off

Run on LibreLane's own DEF/GDS for a second opinion — faster than re-spinning the flow, and it names what diverges where the built-in tools stay terse.

EngineRuns onRole
extractrouted DEFSPEF — second opinion vs OpenRCX (0.997 on a routed block)
sta-sinetlist + real SPEFpost-route timing with the actual parasitics
em-irPDN + currentsIR-drop / electromigration
thermalfloorplan + power mappeak temperature + the hotspot (with leakage ⇄ temp coupling)
lvsextracted GDS + schematicMATCH / MISMATCH with readable diagnostics vs Netgen
drcrouted GDS/OASIS + rule deckgeometry second opinion vs Magic / KLayout — width/space/area/density/antenna/enclosure (+ metal fill)
gds-viewGDS/OASIS + violation markssee where a DRC/LVS failure is — a layered SVG overlay, no GUI

Honest note: these don't change LibreLane's optimizer, so they don't make P&R itself faster. "Faster convergence" means fewer expensive flow spins (you enter with clean inputs) and an independent verdict that catches what the flow's own tools miss or report cryptically. char isn't in this loop — it builds libraries, not per-design checks.

Open core. The moat is the calibration, not the engine.

Every engine here is Apache-2.0, on GitHub, runnable today — and orchestrated end-to-end inside VyBox Sley (the flow container, in early access). What stays private is the only thing that should: the per-foundry calibration plugins (NDA), which encode confidential process data. The engine is open; the fab-specific accuracy is gated.

That mirrors how the rest of the flow treats OpenROAD, Yosys, KLayout, and Magic — commodity steps, openly usable, with the value in how Vyges composes and signs off on them.

Where the engines fit

vyges CLI ─► Catalog + PDK ─► Vyges Loom (engines + spine) ─► VyBox Sley ─► Silicon

This is the missing layer between PDKs and containers — where sign-off becomes software.

Put these in your flow — come talk to us

Questions, or found a bug? Join the discussion on GitHub →