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.

Foundation · the design data

Not an analysis — the database the analyses stand on, and the assembly layer built over it.

Design database · chiplets

vyges-opendb

The design database layer over OpenROAD’s OpenDB — ECO surgery, DEF I/O and a typed query surface, plus 2.5D/3D chiplet assembly: read a 3Dblox stack, check its structure, verify that its die-to-die interfaces actually connect, and draw it.

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.

Analog measurement

vyges-meas

Is the analog block meeting its spec? SNR, SINAD, THD, SFDR from a captured tone; gain, bandwidth, phase margin from a sweep — each number stating the method behind it, and refusing the captures it cannot measure that way.

Process-damage check

vyges-ant

Antenna damage passes every simulation and turns up as yield loss. Checks it on the routed database — the last stage a diode can still fix it — and names the gate and the layer, so you know where the fix goes. Reads both LEF limit forms, so it can't report clean on a technology it never checked.

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), and meas is analog natively: it measures the block's behaviour from captures and sweeps rather than its layout. Digital 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); remap works a level up, re-covering the logic itself for area before placement fixes it in. 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.

Logic-level area

vyges-remap

Re-maps with a multi-output covering, recovering the cells a one-output-at-a-time mapper duplicates — worth most on datapath. Equivalence-checked, and the area delta is measured against a baseline it computes itself.

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.

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.

See it actually happen

A published conformance run — on a clean runner, not our laptop

We publish the run. An AI agent is handed a set of plain-English requests and nothing else — no fine-tuning, no hard-coded command lines — and has to work out which engine to reach for from the engines' own --describe contracts, then run them on a fresh GitHub Actions machine. The report shows what it picked, what it ran, and what came back. It is a demo bundle of the suite, sized to run in minutes on a free runner — not every engine on this page, and the fixtures are small.

Read the latest run report →

Runs on demand rather than on a schedule, so the report is dated — the timestamp on it is the run you are reading. Source and fixtures: vyges-loom-testbench.

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"

All three routes are the same binary. vyges loom, vyges mcp and vyges model ship in the Vyges CLI — install once and you have all three, whether or not you ever point a model at them.

Routes 2 and 3 both run through vyges mcp, the local MCP server — how the engines describe themselves, and how you control what an agent is allowed to change. How it works →

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 →

See it live: an off-the-shelf model drives every Loom engine, from a fresh install → — no fine-tuning, no orchestration code, running in a clean cloud environment.

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.

Engine	Runs on	Catches early
sta-si	synth netlist + `.lib` + SDC	broken constraints, a timing wall, bad clock setup
power	synth netlist + `.lib` + VCD/vectorless	a power / activity problem while it's still cheap to fix
cdc	synth netlist + `.lib` + SDC	an unsynchronized clock-domain crossing — before it's a silicon-only metastability bug
glitch	synth netlist + `.lib`	a reconvergent-fanout glitch on an async / latch / clock-gate path
lec	two netlists + `.lib`	a 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.

Engine	Runs on	Role
extract	routed DEF	SPEF — second opinion vs OpenRCX (0.997 on a routed block)
sta-si	netlist + real SPEF	post-route timing with the actual parasitics
em-ir	PDN + currents	IR-drop / electromigration
thermal	floorplan + power map	peak temperature + the hotspot (with leakage ⇄ temp coupling)
lvs	extracted GDS + schematic	MATCH / MISMATCH with readable diagnostics vs Netgen
drc	routed GDS/OASIS + rule deck	geometry second opinion vs Magic / KLayout — width/space/area/density/antenna/enclosure (+ metal fill)
gds-view	GDS/OASIS + violation marks	see 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.

Vyges™ Loom

Every engine, one spine

vyges-opendb

vyges-char

vyges-extract

vyges-sta-si

vyges-em-ir

vyges-power

vyges-thermal

vyges-lvs

vyges-meas

vyges-ant

vyges-resize

vyges-vt-swap

vyges-buffer-insert

vyges-hold-fix

vyges-remap

vyges-drc

vyges-cdc

vyges-glitch

vyges-lec

vyges-gds-view

`vyges-loom` — the cross-engine data spine

It's real software

Three ways to drive Loom — AI is optional

No AI at all

Claude Code · Cursor · VS Code

Register a model; Vyges drives it

A published conformance run — on a clean runner, not our laptop

Already using SemiKong?

Deterministic execution

Your design never leaves your box

`loom.feedback` — the agent's eyes

Already on OpenLane / LibreLane? Drop these in.

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

After the flow produces layout — independent fast sign-off

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

Where the engines fit

Vyges™ Loom

Every engine, one spine

vyges-opendb

vyges-char

vyges-extract

vyges-sta-si

vyges-em-ir

vyges-power

vyges-thermal

vyges-lvs

vyges-meas

vyges-ant

vyges-resize

vyges-vt-swap

vyges-buffer-insert

vyges-hold-fix

vyges-remap

vyges-drc

vyges-cdc

vyges-glitch

vyges-lec

vyges-gds-view

vyges-loom — the cross-engine data spine

It's real software

Three ways to drive Loom — AI is optional

No AI at all

Claude Code · Cursor · VS Code

Register a model; Vyges drives it

A published conformance run — on a clean runner, not our laptop

Already using SemiKong?

Deterministic execution

Your design never leaves your box

loom.feedback — the agent's eyes

Already on OpenLane / LibreLane? Drop these in.

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

After the flow produces layout — independent fast sign-off

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

Where the engines fit

`vyges-loom` — the cross-engine data spine

`loom.feedback` — the agent's eyes