# Vyges > Vyges is AI-native silicon engineering: bring your AI model, your PDK, and your IP, and turn them into fab-ready silicon in weeks, not months. A model reasons about the design; deterministic engines do the work. Vyges includes an open registry of verified hardware IP (150+ blocks), a suite of open-source EDA sign-off engines (Apache-2.0) that any AI model can drive locally through `vyges mcp`, an end-to-end flow, and a taped-out SoC — so teams design, verify, and tape out chips without six-figure tool licenses. Vyges is the execution layer for AI-native silicon engineering. Any AI model — Claude, OpenAI, Grok, an open-weight model (Qwen, Llama, DeepSeek), or a semiconductor-specific model such as SemiKong — can drive the deterministic engines through the open **Model Context Protocol** (`vyges mcp`), on your own hardware so RTL never leaves the building; or run the engines manually from the CLI and CI. The model is **open core**: the engines and tooling are open and runnable today; the only thing gated is per-foundry **calibration plugins** (NDA), which encode confidential process data. Standard file formats (Liberty, SPEF, SPICE, GDSII/OASIS, structural Verilog/Yosys JSON) in and out, declarative job files instead of Tcl, and CI-native exit codes throughout. The engine algorithms are **clean-room Rust**, written from published behaviour rather than ported or wrapped, and ship as single self-contained binaries with no Tcl interpreter, no Python runtime, no nix store and no container to stand up. The design database underneath is **OpenROAD's OpenDB** (BSD-3-Clause), used deliberately rather than replaced: the same `.odb` round-trips between these engines and an existing OpenROAD flow, so a team can adopt one engine without migrating anything else and without being locked in to having done so. Licensing is **Apache-2.0 with no copyleft anywhere in the dependency graph** — the timing engine included, which is unusual in this space — so they can be embedded in commercial products and shipped to customers without a license review. And they are **integrated rather than assembled**: one CLI installs them, one cross-engine data spine carries each artifact from the engine that produces it to the engine that consumes it, and every engine answers `--describe` with a machine-readable contract stating its inputs, outputs, scope and limits. They are usable **alongside or in place of the tools already in a flow, engine by engine** — a second opinion on timing or geometry, a faster gate before an expensive stage — rather than as a whole-flow swap: placement, clock-tree synthesis and routing are not implemented, so a flow still needs its existing place-and-route. AI models are replaceable; the silicon flow isn't. Everything below is canonical; descriptions are written to be honest about scope and bounds. > This is the full-content companion to /llms.txt — each linked page's content inlined for one-fetch ingestion. Generated from the site; do not edit by hand. --- ## EDA sign-off engines (open-core, Apache-2.0) ### EDA Engines overview Source: https://vyges.com/products/loom/ #### Vyges™ Loom Commercial-grade engines for silicon implementation and sign-off — the engines that build the block, 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. Hover to zoom · click to open the full-size diagram This architecture is written up in full — figure and all — in our paper, Vyges Loom: A Shared Data-Spine Architecture (open access, DOI-archived). 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. Physical construction · build Build the block — the floorplan and its rows, the well taps and endcaps, the power grid, the IO pins and pad ring, and the fill that meets density. They write straight into the same design database the rest of the suite reads, so the block you sign off is the block you built — no DEF round-trip, no exchange format in between, nothing lost in translation. Placement, CTS and routing stay the flow’s job. Floorplan & rows ###### vyges-ifp Turns a die rectangle into a floorplan: the core area, the site grid, and the rows every later stage places into. Snapping is the whole job — the core you get back is what the rows cover, not what you asked for, because that is what the design actually has. Hybrid sites and row parity included. Macro placement ###### vyges-mpl Puts the macros down — either at the origins your config already states, each left fixed, or derived by clustering, coarse shaping and annealing. A design with no unfixed macros reports vacuous, never a placement it did not make. A flat cluster past the level threshold is refused rather than approximated: a plausible-looking macro placement that is wrong costs more than a refusal. Well taps & endcaps ###### vyges-tap Cuts rows around macros and places the physical cells that keep the wells tied and the row ends legal — well taps and endcaps, matched to position, orientation and master. A macro that is not placed is named in the report, never silently skipped, because rows would otherwise be cut for a location nothing occupies. Power grid ###### vyges-pdn Builds the power distribution network — rings, straps, follow pins, and the vias that stitch the layers together — then publishes the supply nets as block terminals so the next tool can find them. Refuses a grid the technology cannot hold (a strap off-track, a connect naming a non-routing layer) before writing geometry. IO pin placement ###### vyges-ppl Places IO pins on the die boundary where they cost the least wire — optimal matching within each section, with excluded regions, region constraints, pin groups and mirrored pairs honoured. A constrained pin that does not fit is reported unplaced, not quietly relocated: somewhere else is not a smaller version of the answer you asked for. IO ring & pads ###### vyges-pad Lays the ring of IO rows around the die — corners sized from the corner site, edges truncated to whole sites — and places pads and corners into it. Legality is checked layer by layer, not by bounding box, so a bump never blocks a cell it merely overlaps. Density fill ###### vyges-fin Fills the gaps with metal fill until every layer meets its density floor, OPC sections included. Existing fill is cleared first, so re-running is idempotent rather than cumulative — and a run that placed nothing reports vacuous, never a clean fill it did not do. ###### Seconds, not stages One binary per step. Nothing to stand up, nothing to orchestrate, no container to warm. Iterate on a floorplan or a grid as fast as you can think of the next thing to try. ###### Errors you can act on Not “failed”. Which cell, which layer, which rule rejected it and what it wanted instead — so the next thing you do is the fix, not a bisect. ###### It fails before it writes An illegal grid or an unbuildable floorplan costs you a message, not a corrupted database and an afternoon working out where it went wrong. Bringing a block through this? Tell us what you are building — we work directly with the teams using these, and turnaround on a real blocker is measured in days. 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. ##### 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. 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. 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 + `.lib`a reconvergent-fanout glitch on an async / latch / clock-gate path lectwo 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. 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 Want the design rationale first? Read the papers behind Loom — the data-spine architecture and how we let AI drive it safely → Questions, or found a bug? Join the discussion on GitHub → ### vyges-opendb Source: https://vyges.com/products/loom/opendb/ Vyges Loom #### vyges-opendb The design database, and the chiplet assembly layer on top of it — read a 2.5D/3D assembly, check its structure, check that its die-to-die interfaces actually connect, and draw it. One binary, no GUI, no Tcl. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone building a multi-die product, and any step that needs to read or edit a placed design directly. `vyges-opendb` is a safe Rust API and CLI over OpenROAD's OpenDB — the in-memory design database that physical steps read and edit. It sits a layer below the sign-off engines: not an analysis, but the design data an analysis operates on. The division of labour is simple: OpenDB provides the data model; Vyges Loom provides the executable workflows built on that model. On top of the flat design surface — ECO surgery, DEF I/O, connectivity and wire-length reports, a generic typed query surface — it adds the 2.5D/3D chiplet assembly layer: read a 3Dblox assembly natively into the database, run seven structural checks over it, verify that the bumps on two mating faces actually meet and carry the same signals, and render the whole stack as a cross-section. 3Dblox assembly ──► vyges-opendb ──► structural verdict + interface verdict + a drawing ##### Chiplet assembly verification Two dies are only connected if the microbumps on their mating faces physically land on each other and carry the same signals. Structural checks confirm the dies are the right size, in the right place and correctly oriented — and a die-to-die interface can pass every one of them while being electrically dead. `check-d2d` is the check that closes that gap: unmated bumps, misalignment with the distance reported, net mismatch and bump-cell mismatch — each finding naming the bumps involved. We are not aware of another open-source tool that verifies this. vyges opendb read-3dblox --input stack.3dbx --output stack.odb vyges opendb check-3dblox --input stack.odb vyges opendb check-d2d --input stack.3dbx vyges opendb view-3dblox --input stack.3dbx --output stack.svg Each emits JSON and exits non-zero on a violation, so they gate CI directly. Read the series: describing a stack, why structural checking is not enough, and the end-to-end flow. ##### How it is built No Tcl, no SWIG, no OpenROAD engines. It pins an OpenROAD commit, sparse-checks-out just the database sources, and compiles a standalone static `libodb`. The result is a single binary whose only dynamic dependencies are the C runtime and zlib — no Python, no interpreter, no virtualenv, and no shared library to find at run time. Every subcommand is self-describing (`--describe` emits a typed JSON contract), so `vyges mcp` exposes it to an AI assistant with no plugin or adapter. The model proposes; the deterministic engine decides. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges opendb info --input design.odb # block name + inst/net/port counts $ vyges opendb read-3dblox --input stack.3dbx --output stack.odb # assembly → database $ vyges opendb check-3dblox --input stack.odb # structural verdict $ vyges opendb check-d2d --input stack.3dbx # do the interfaces connect? $ vyges opendb view-3dblox --input stack.3dbx --output stack.svg # cross-section + plan Linux (x86-64 and arm64) and macOS (Apple Silicon). Not available on Windows — it builds on OpenROAD’s libodb, which is unix-only; use WSL2. Apache-2.0, built on OpenROAD’s OpenDB (BSD-3-Clause). --- ## Physical construction engines (open-core, Apache-2.0) ### vyges-ifp Source: https://vyges.com/products/loom/ifp/ Vyges Loom · Physical construction #### vyges-ifp Turn a die rectangle into a floorplan a tool can place into. Die area, core area, the site grid, and the rows every later stage fills — including hybrid sites and row parity. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone starting a block — this is the first thing that runs, and everything downstream inherits whatever it decides. A floorplan is not a rectangle. It is a core area snapped to a site grid, tiled with rows of a definite height, orientation and phase — and every placer, every tap inserter and every power grid after it is built on those rows. Get the grid wrong and nothing downstream is legal. `vyges-ifp` takes the die and core rectangles in microns, resolves the site set, and builds the rows. Hybrid sites tile from their declared row pattern; row parity trims the count where a design needs an even or odd number of rows. `.odb` + die/core rectangles + site ──► vyges-ifp ──► rows, core area, instance census ##### The core you get back is not always the core you asked for The core’s lower-left corner is snapped up to the site grid; the upper right is left alone. What finally gets stored is what the rows cover — not the rectangle you passed in. That is deliberate, and it is load-bearing. A caller that reads the core area back will not always see its own argument, because the honest answer is the area the design actually has. An engine that echoed your input would be easier to explain and wrong. Rows are numbered globally across sites, so adding a site renumbers the rows after it — stated up front rather than discovered downstream. ##### Refusals come before writes A macro larger than the core is refused before anything is snapped or written, and a design with both an empty die and an oversized macro reports the die first — the checks run in a fixed order so the same input always produces the same complaint. A database with no DBU scale is an error, not an assumed scale. Guessing the units of a floorplan is how a block ends up a thousand times too big. Scope, stated plainly: this implements the explicit-rectangle form. The utilization / aspect-ratio form, which derives the die from placed cell area, is not built — pass rectangles. UPF power domains are a known gap: the floorplan geometry matches, the power-domain instances are not inserted. ##### Try it $ vyges install physical # one-time: fetch the construction engines into ~/.vyges/bin $ vyges physical ifp run design.odb --die-area '0 0 200 200' \ --core-area '10 10 190 190' --site unithd # build the floorplan $ vyges physical ifp run design.odb ... --row-parity EVEN # trim the rows to an even count $ vyges physical ifp run design.odb ... --dry-run # plan it, write nothing Exit status is the verdict: 0 applied · 1 refused (empty die, core outside it, no row fits) · 2 error — so CI gates on the exit code without parsing prose. ##### Where it sits in the flow First. vyges-tap cuts the rows this builds, vyges-pdn runs its follow pins along them, and every placer downstream fills them. Output is in place over the input database by default — pass `--out-odb` to write elsewhere. ###### 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 → ### vyges-mpl Source: https://vyges.com/products/loom/mpl/ Vyges Loom · Physical construction #### vyges-mpl 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. Download All Loom engines View source on GitHub → ##### What it does 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 run that did nothing says so 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. ##### What it refuses, and why that is the honest answer 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. ##### Try it $ vyges install physical # one-time: fetch the construction engines into ~/.vyges/bin $ vyges physical mpl place-macro design.odb \ --macro sram0=120.5,240.8 --macro sram1=520.0,240.8,MY # origins in microns $ vyges physical mpl place-macro design.odb --macro sram0=120500,240800 --dbu # database units instead $ vyges physical mpl run design.odb # cluster, shape and anneal 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. ##### Where it sits in the flow 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. ###### 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 → ### vyges-tap Source: https://vyges.com/products/loom/tap/ Vyges Loom · Physical construction #### vyges-tap 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. Download All Loom engines View source on GitHub → ##### What it does 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) ##### Two masters for one position is an error, not a coin flip 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. ##### An unplaced macro is named, never skipped 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. ##### Try it $ vyges install physical # one-time: fetch the construction engines into ~/.vyges/bin $ vyges physical tap cut-rows design.odb --halo-x 2 --halo-y 2 # cut rows around the macros $ vyges physical tap place-endcaps design.odb --corner CORNER_A # cap the row ends and corners $ vyges physical tap place-tapcells design.odb --master TAPCELL --distance 25 # distribute the well taps $ vyges physical tap tapcell design.odb --tapcell-master T --endcap-master E # all of it, in one step $ vyges physical tap ripup design.odb --tap-prefix TAP_ # undo just the taps Status is one of applied · planned (dry run) · vacuous · error — and the declared assertion passes only on applied. ##### Where it sits in the flow 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. ###### 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 → ### vyges-pdn Source: https://vyges.com/products/loom/pdn/ Vyges Loom · Physical construction #### vyges-pdn Build the power grid — and refuse the one the technology cannot hold. Rings, straps, follow pins and the vias that stitch them together, published as block terminals the next tool can actually find. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone who needs power to reach the cells — and anyone who has debugged a grid that looked fine until the via stage. The power distribution network is the structure everything else sits inside. It is built from a small vocabulary — rings around the core, straps across it, follow pins along the standard-cell rows — and then vias connect the layers wherever those shapes cross. `vyges-pdn` builds all four, on the shared design database, and publishes each supply net as a block terminal so the next tool in the flow can find the grid rather than infer it. `.odb` + grid spec (rings, straps, follow pins) ──► vyges-pdn ──► grid shapes, vias, block terminals ##### A grid the technology cannot hold is refused before it is drawn Most of the cost of a power grid is discovering, late, that some part of it was never legal. So the checks run first: a strap that cannot snap to the routing tracks or fit its grid is refused; a connect rule that names one layer twice, or names a layer that is not a routing layer, is refused — by name, with the rule that rejected it. Spacing derived from the technology is snapped to the manufacturing grid, not left on an off-grid fraction that fails much later in a DRC deck. Via arrays widen their cut pitch where `ADJACENTCUTS` applies, and a via built once is reused for every crossing of the same size — the geometry is built after trimming, the way the database expects to receive it. ##### Most of a power grid’s cost is finding out late A grid that is subtly wrong does not announce itself. It survives generation, survives the via stage, and turns up much later as a DRC deck full of noise or a block that will not route — by which point the cheap fix is hours behind you. So this refuses up front, by name: the strap that cannot snap to tracks, the connect rule naming a layer that is not a routing layer, the dimensions the layer will not allow. You get the rule that rejected it and what it wanted — a message you act on in a minute, not a symptom you spend an afternoon tracing back. And it runs in seconds from one binary, so trying three grid styles before lunch is a normal afternoon rather than a scheduling decision. (One thing worth knowing if you diff this against another tool: shapes are emitted before trimming, which belongs with the via stage — skip trimming on the other side and you are comparing like with like.) ##### Try it $ vyges install physical # one-time: fetch the construction engines into ~/.vyges/bin $ vyges physical pdn generate design.odb --out-def pdn.def \ --power VDD --ground VSS --followpins met1 # follow pins on the rows $ vyges physical pdn generate design.odb --out-def pdn.def --power VDD --ground VSS \ --ring 'met4,met5:2:2:1' --stripe 'met4:1.6:40:10' # a ring and straps over it $ vyges physical pdn --describe # the machine-readable contract, scope and measured figures Emits the grid as DEF plus a JSON report on stdout, and exits non-zero on a refusal — so CI gates on the exit code without parsing prose. ##### Where it sits in the flow After vyges-ifp and vyges-tap — follow pins run along the rows, so the rows have to exist and be cut first. The grid it builds is what vyges-em-ir later analyses for IR drop and electromigration: the same database, built and checked by the same suite. ###### 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 → ### vyges-ppl Source: https://vyges.com/products/loom/ppl/ Vyges Loom · Physical construction #### vyges-ppl Put the IO pins where they cost the least wire. Optimal matching within each section — with excluded regions, region constraints, pin groups and mirrored pairs all honoured, not approximated. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone placing pins on a block boundary, where a bad assignment costs wirelength on every net that crosses it. Every pin on a block boundary is a decision that the router then has to live with. Placed badly, pins add wire to every net that reaches them — and unlike most placement problems, this one has a clean optimum within a section. `vyges-ppl` generates the legal slots from each layer’s routing tracks, cuts them into sections, and solves the assignment optimally inside each one — cost being half-perimeter wirelength over the net bounding box. `.odb` + layer choice + constraints ──► vyges-ppl ──► pin positions, total wirelength, unplaced pins named ##### A constrained pin that does not fit is reported unplaced, not relocated If you constrain a pin to a region and it does not fit, this says so. It does not put the pin somewhere else and call the job done — the design asked for a region, and somewhere else is not a smaller version of that answer. The same principle runs through the ordering. Constrained pins are placed before free ones, and their slots are withdrawn, because the reverse order lets a pin with alternatives take the only position a constrained pin had. Groups go before individual pins, since one pin dropped into the only long-enough run destroys it irrecoverably. Mirrored pairs go first of all — they need two positions open at once, so they have the least room to manoeuvre. A mirrored pair is one decision, not two: if the reflection is unavailable, both halves are reported unplaced. Half a pair is a broken symmetry, not a partial success. ##### Score your current placement against it The optimal assignment cost is unique, but the optimal pairing is not: two placements can swap a pair of pins and both be exactly right. So a placement that looks different from yours is not necessarily a worse one — and you should not have to guess which. That is what `--evaluate` is for: hand it the placement you are using today and it scores that under the identical cost model. One number, one run, and you know whether changing anything is worth your time — before you rebuild a flow around it. So far it has matched or beaten every placement scored this way, and never come out worse. Scope, stated plainly: it reports the chosen positions rather than writing pin rectangles into the database, which depends on pin-length handling that is not built. Slot availability accounts for excluded regions and fixed ports’ metal, but not yet for macros or routing obstructions — so where a macro abuts the boundary, availability stays optimistic. Both are in the engine’s own `--describe`, so neither is a surprise you find later. ##### Try it $ vyges install physical # one-time: fetch the construction engines into ~/.vyges/bin $ vyges physical ppl slots design.odb --hor-layers met3 --ver-layers met2 # what slots exist, and why $ vyges physical ppl place-pins design.odb --hor-layers met3 --ver-layers met2 # assign the pins optimally $ vyges physical ppl place-pins design.odb ... --min-distance 2 --corner-avoidance 5 # spacing and corner keep-out $ vyges physical ppl place-pins design.odb ... --evaluate reference.json # score someone else’s placement the same way Reports the assignment and its total wirelength as JSON, and names every pin it could not place — a clean run never hides an unplaced pin. ##### Where it sits in the flow After the die and core exist (vyges-ifp) and before routing, since the router needs to know where the boundary pins are. Constraints are read back from the database, where the flow stores them — not passed on the command line — so a constraint set by an earlier step is honoured without being restated. ###### 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 → ### vyges-pad Source: https://vyges.com/products/loom/pad/ 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. Download All Loom engines 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 → ### vyges-fin Source: https://vyges.com/products/loom/fin/ Vyges Loom · Physical construction #### vyges-fin Fill the gaps until every layer meets its density floor. Verified shape for shape, and safe to re-run — fill is cleared and regenerated wholesale, so it never accumulates. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone streaming out to a foundry — density rules are a tape-out gate, and fill is how you pass them. Foundries require each metal layer to carry a minimum density across the die, because chemical-mechanical polishing behaves badly over large empty regions. Meeting that floor means placing fill shapes into every gap the design leaves — without touching a real wire, a real instance or a real obstruction. `vyges-fin` computes the non-fill area per layer as the union of every placed instance’s shapes, every routed wire box (vias decomposed) and every obstruction, then tiles what remains with shapes of the sizes the rules declare. `.odb` + JSON fill rules ──► vyges-fin ──► fill shapes (layer, mask, OPC flag, coordinates) ##### Re-running it twice gives you the same design, not twice the fill Existing fill is cleared before filling. Fill is regenerated wholesale, never patched — so running the step again is idempotent, and an incremental flow that touches it repeatedly does not accumulate junk. OPC fill is placed only where the rules declare an `opc` section, and only after non-OPC fill, clearing both the design and the fill just placed — so the two passes cannot overlap each other. A layer the rules never mention is skipped and reported, not silently filled with a guess. ##### A run that filled nothing says so Status is one of filled, planned, vacuous or error — and vacuous is not filled. It means the run placed no shape at all, and the declared assertion passes only on filled, so a no-op fails rather than reporting work that never happened. Zero can still be the right answer — a design already above every density floor needs no fill — which is exactly why the engine reports the counts and lets you decide, instead of deciding for you. Density is a tape-out gate, and fill is the least interesting way to miss one. Every fill is a whole shape of a size the rules declare, no two on a layer overlap, and a layer the rules never mention is skipped and reported rather than filled with a guess. It is the part of sign-off you should be able to stop thinking about. Not maximal, and it says so: the tiling is a fixed grid anchored at each sub-area’s bounding box rather than a swept origin, so density is not maximal by construction — and the spacing check is deliberately conservative, which can exclude a position that would in fact have been legal. ##### Try it $ vyges install physical # one-time: fetch the construction engines into ~/.vyges/bin $ vyges physical fin density-fill design.odb --rules fill-rules.json # fill to the density floor $ vyges physical fin density-fill design.odb --rules fill-rules.json \ --area '0 0 500 500' # fill one rectangle only $ vyges physical fin density-fill design.odb --rules fill-rules.json --dry-run # plan it, write nothing Exit status is the verdict: 0 filled or vacuous (read the count) · 1 refused · 2 error. ##### Where it sits in the flow Last, or nearly — after routing, when the gaps are final. The fill it places is geometry that vyges-drc then checks for density on the streamed-out layout: one suite builds the fill, another proves it met the rule. ###### 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 → ### vyges-char Source: https://vyges.com/products/loom/char/ Vyges Loom #### vyges-char Standard-cell characterization — generate Liberty (`.lib`) timing & power models from SPICE, in parallel, from one declarative job. Download All Loom engines View source on GitHub → ##### What it does Used by: PDK teams, standard-cell library developers, and platform teams validating reusable IP. `vyges-char` takes SPICE models and a cell list and produces a Liberty library — the timing and power model every downstream sign-off step (STA, power) depends on. It orchestrates the underlying SPICE runs in parallel, which is the piece the open-source flow has historically lacked; it is validated against reference Liberty for the open PDKs. The emitted Liberty is standard Liberty that downstream sign-off tools consume directly, and supports multi-corner, multi-voltage characterization. SPICE models + cell list ──► vyges-char ──► .lib (Liberty timing & power) ##### One declarative job A `.char` / `.charlib` job file declares the corner(s), the cells, and the collateral — no imperative scripting. Standard CLI: `--json`, `--quiet`, `--verbose`, `-h` / `-V`. The `.lib` it emits is read directly by vyges-sta-si, and its per-switch energy seam feeds vyges-em-ir. One declarative job in; one standard sign-off artifact out. Exits non-zero on violations — designed to gate CI, not generate PDFs. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom char demo # instant — print a sample .lib, no setup $ vyges loom char run inv.char -o inv.lib # one cell → Liberty (.lib) $ vyges loom char library cells.charlib -o out/ # many cells, in parallel → merged .lib ##### Predict the grid instead of simulating all of it Characterization's cost is the SPICE sweep — one simulation per slew × load point, per arc, per corner. But delay and transition are smooth functions of slew and load, so `vyges-char` can simulate a coarse subset and predict the rest: export a tidy dataset, fit a small model, and fill the dense library — `--sparse` for a fixed coarse grid, or `--auto` to self-tune to a target accuracy. All in pure Rust — experiment with GPUs too via rust-gpu — and it runs locally: nothing leaves your machine. ###### Researchers & universities A study in sample-efficiency and surrogate modeling on open PDKs — how few simulations for a given accuracy, which models, which cells and corners. Publish and share. ###### Enterprise silicon teams Evaluate the payoff on your PDK — across mature and advanced node PDKs. Characterize a few representative cells and measure how much characterization time `--sparse` / `--auto` saves at an accuracy your flow accepts — all on your confidential models, locally. Try it and tell us what you find — the experiment guide is on GitHub; share results or talk through your flow at vyges.com/contact. ###### Open core · Apache-2.0 Open and runnable today, and inside VyBox Sley. The per-foundry calibration plugins (NDA) stay private — the engine is open, the fab-specific accuracy is gated. See all the engines & the data spine → ### vyges-extract Source: https://vyges.com/products/loom/extract/ Vyges Loom #### vyges-extract Interconnect parasitic extraction — turn a layout's RC into SPEF, from one declarative job, so timing and power see the real wires. Analog and mixed-signal layouts too — RC is geometry, not cell-specific. Download All Loom engines View source on GitHub → ##### What it does Used by: physical-design flows that want timing and power to see real wires — not estimates. `vyges-extract` reads a layout and the PDK's parasitic rules and produces SPEF — the resistance and capacitance of every net. That's what lets static timing and power analysis reason about the actual interconnect, not an idealized one. SPEF is the standard hand-off the downstream engines expect. Extraction accuracy is governed by the PDK's parasitic rules — the engine is open, the calibration is foundry-specific; it handles hierarchical, full-chip designs. layout (DEF/LEF) + parasitic rules ──► vyges-extract ──► .spef (RC parasitics) ##### One declarative job An `.ext` job file declares the design, the PDK collateral, and the extraction settings. Standard CLI: `--json`, `--quiet`, `--verbose`. The `.spef` it emits is read directly by vyges-sta-si — one cross-engine data spine, no manual file shuffling. One declarative job in; one standard sign-off artifact out. Exits non-zero on violations — designed to gate CI, not generate PDFs. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom extract demo # instant — print a sample SPEF, no setup $ vyges loom extract run design.ext -o design.spef # extract RC → SPEF $ vyges loom extract run design.ext --json # per-net R/C summary ###### Open core · Apache-2.0 Open and runnable today, and inside VyBox Sley. The per-foundry calibration plugins (NDA) stay private. See all the engines & the data spine → ### vyges-power Source: https://vyges.com/products/loom/power/ Vyges Loom #### vyges-power Power analysis — leakage + internal + switching from a netlist and activity, against a budget. Emits the per-instance activity that em-ir needs. Download All Loom engines View source on GitHub → ##### What it does Used by: teams who need a power number early — and the activity map that makes IR-drop analysis real. `vyges-power` reads a gate-level netlist and the Liberty models and computes power — leakage, internal, and switching — from either a vectored activity file (VCD) or vectorless probabilistic toggling. Just as importantly, it emits the per-instance activity / current map that vyges-em-ir consumes, so IR-drop is solved from real per-instance current instead of a worst-case assumption — closing the `char → power → em-ir` loop. netlist + .lib + activity (VCD / vectorless) ──► vyges-power ──► power report + activity map → em-ir ##### One declarative job A `.pwr` job file declares the netlist, the Liberty models, the activity source, and the budget. It can read extracted wire caps (`.spef`) from vyges-extract for switching power, and writes the activity annotation em-ir reads — one cross-engine spine, no glue scripts. One declarative job in; a power report out, plus the activity map downstream. `--fail-on-budget` gates CI. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom power demo # instant — built-in design, no setup $ vyges loom power run block.pwr # leakage + internal + switching report $ vyges loom power run block.pwr --fail-on-budget # exit 3 over budget — CI gate ###### Open core · Apache-2.0 Open and runnable today, and inside VyBox Sley. See all the engines & the data spine → ### vyges-sta-si Source: https://vyges.com/products/loom/sta-si/ Vyges Loom #### vyges-sta-si Static timing analysis with signal integrity — WNS / TNS and the worst path, from one declarative job, with a CI gate that fails on a violation. Download All Loom engines View source on GitHub → ##### What it does Used by: platform and PD teams gating timing on every commit — sign-off as a check, not a late-stage review. `vyges-sta-si` checks whether the design meets timing — reporting worst negative slack (WNS), total negative slack (TNS), and the critical path — while accounting for signal-integrity coupling between nets (crosstalk-induced delay and noise effects). It reads the `.lib` from vyges-char and the `.spef` from vyges-extract — the two upstream artifacts on the spine. The timing results and slack metrics are sign-off compatible with standard Liberty and SPEF inputs — no proprietary formats, no hidden transforms. .lib + .spef + design & constraints ──► vyges-sta-si ──► WNS / TNS / worst path ##### One declarative job · built to gate CI A `.sta` job file declares the libraries, parasitics, and constraints. Standard CLI: `--json`, `--quiet`, `--verbose` — plus `--fail-on-violation`, which returns a distinct exit code so a timing violation fails your pipeline automatically. This turns timing sign-off from a late, manual review step into a deterministic CI check. One declarative job in; one standard sign-off artifact out. Exits non-zero on violations — designed to gate CI, not generate PDFs. ##### Feeds the flow — and lints the constraints SDF back-annotation · `--sdf` Writes a standard SDF — per-cell delays, setup/hold timing checks, and SPEF-derived interconnect delays — the hand-off a gate-level / back-annotated simulator consumes, produced from the same Liberty + SPEF, with no Tcl and no external STA. SDC lint · `sdc-lint` A correct slack report is worthless if the constraints are wrong. `sdc-lint` checks the SDC itself — unconstrained I/O, a missing or zero-period clock, a duplicate, a clock on a port the design lacks — independent of the timing run. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom sta-si demo # instant — analyze a built-in design → WNS/TNS $ vyges loom sta-si run top.sta -o top.rpt # analyze → timing report $ vyges loom sta-si run top.sta --fail-on-violation # exit 3 if WNS < 0 (CI gate) $ vyges loom sta-si run top.sta --sdf top.sdf # also write SDF for gate-level sim $ vyges loom sta-si sdc-lint top.sta # check the constraints themselves ###### Open core · Apache-2.0 Open and runnable today, and inside VyBox Sley. The per-foundry calibration plugins (NDA) stay private. See all the engines & the data spine → ### vyges-em-ir Source: https://vyges.com/products/loom/em-ir/ Vyges Loom #### vyges-em-ir Power-integrity sign-off — solve the power-distribution network for IR-drop and electromigration against a budget, from one declarative job. Digital, analog and mixed-signal power grids alike — it's grid physics, not a standard-cell construct. Download All Loom engines View source on GitHub → ##### What it does Used by: teams enforcing power budgets before tape-out, not after surprises. `vyges-em-ir` takes the design's power-distribution network (PDN) and solves it — reporting IR-drop (how much supply voltage the grid loses) and checking electromigration (EM) current limits against a budget. The per-switch energy seam from vyges-char feeds its dynamic solve, so power integrity is consistent with the cells' characterized behavior. It reports both steady-state and dynamic IR-drop. This turns power integrity from a late, manual sign-off step into a deterministic, CI-gated check. design + PDN + IR/EM budget ──► vyges-em-ir ──► IR-drop map + EM check ##### One declarative job An `.emir` job file declares the design, the PDN, and the IR/EM budget. Standard CLI: `--json`, `--quiet`, `--verbose` — and like the timing engine, it can fail CI on a budget violation. No bespoke setup; the same declarative shape as the rest of the spine. One declarative job in; one standard sign-off artifact out. Exits non-zero on violations — designed to gate CI, not generate PDFs. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom em-ir demo # instant — analyze a built-in PDN → IR/EM $ vyges loom em-ir run block.emir -o block.rpt # analyze → report $ vyges loom em-ir run block.emir --fail-on-violation # exit 3 if over budget (CI gate) ###### Open core · Apache-2.0 Open and runnable today, and inside VyBox Sley. The per-foundry calibration plugins (NDA) stay private. See all the engines & the data spine → ### vyges-thermal Source: https://vyges.com/products/loom/thermal/ Vyges Loom #### vyges-thermal On-chip thermal sign-off — the peak temperature and the hotspot from the same power map, with electro-thermal coupling. Analog and mixed-signal blocks too — heat flow is technology-agnostic. Download All Loom engines View source on GitHub → ##### What it does Used by: teams that want to find the hotspot before the package does. `vyges-thermal` takes the design's floorplan power map — the per-instance power vyges-power already produces — and solves the die's heat flow: where the heat concentrates, the peak temperature, and the hotspot location, with a PASS/FAIL against a temperature limit. It is the thermal dual of vyges-em-ir: the same grid solve, temperature where em-ir has voltage. And because leakage rises with temperature, it runs the electro-thermal loop to a fixed point — leakage heats the die, the hotter die leaks more — so you get the real operating temperature, not a cold-start estimate. This turns thermal from a late packaging surprise into a deterministic, CI-gated check. floorplan + power map + temp limit ──► vyges-thermal ──► temperature field + hotspot That closes the power-integrity spine end to end: `char → power → em-ir → thermal → power` — one shared activity map, landed on the die as current and as heat. ##### One declarative job A `.thermal` job declares the die, the grid, the material parameters, and the temperature limit; a `.flp` floorplan places the blocks and their power. Standard CLI: `--json`, `--quiet`, `--verbose` — and like the rest of the spine it can fail CI when the peak exceeds the limit. One declarative job in; a temperature field, the hotspot, and a verdict out. Exits non-zero over the limit — designed to gate CI, not generate PDFs. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom thermal demo # instant — a built-in floorplan → temperature + heat map $ vyges loom thermal run block.thermal -o block.rpt # analyze → report $ vyges loom thermal run block.thermal --fail-on-violation # exit 3 over the limit (CI gate) ###### Open core · Apache-2.0 Open and runnable today, and inside VyBox Sley. The per-foundry/package calibration plugins (NDA) stay private. See all the engines & the data spine → ### vyges-lvs Source: https://vyges.com/products/loom/lvs/ Vyges Loom #### vyges-lvs Layout-vs-schematic — does the layout implement the schematic? A MATCH / MISMATCH verdict with diagnostics that name where it diverges. Digital, analog and mixed-signal netlists alike — the device-graph compare is technology-agnostic. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone signing off a layout — and anyone who has lost an afternoon to a cryptic mismatch report. A layout is only correct if it implements the schematic — same devices, same connectivity. `vyges-lvs` proves that by matching the two netlists as graphs, independent of how nets and instances happen to be named (name-independent colour-refinement). When they don't match, the only thing that matters is where — so it names the unmatched devices and nets, where the open incumbent (Netgen) prints a terse "do not match." It can also extract the layout netlist straight from GDS, so you don't need a separate extractor in the loop. layout netlist (or GDS + rules) + schematic ──► vyges-lvs ──► MATCH / MISMATCH + diagnostics ##### Correlated against the golden tools Not a toy — checked against the reference open extractors and comparators on real sky130: - ✓ Magic, exact: on a real sky130 cell (`inv_1`) the native GDS extraction is net-level identical to Magic's golden netlist — a full LVS MATCH, hvt variant included. - ✓ At scale: on a placed-and-routed block (the counter through OpenLane, 229 cell instances) it reaches exact device parity with Magic — 842 transistors, 421 n / 421 p, decap MOSCAPs included — in ~1.5 s. - ✓ Netgen, agreed: on the verdict itself, `vyges-lvs` and Netgen agree 3/3 (MATCH on renamed/reordered nets; MISMATCH on a dropped cell and a swapped net) — with `vyges-lvs` naming the unmatched classes. ##### One declarative job A `.lvs` job file names the two netlists to compare — or a `.gds` / `.oas` + a layer `.rules` deck to extract the layout side natively first. Standard CLI: `--json`, `--quiet`, `--verbose`, and a `--fail-on-mismatch` exit code that gates CI. Describe the comparison, not a tool-specific rule script. One verdict out, with the divergence named. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom lvs demo # instant — built-in netlist pair, no setup $ vyges loom lvs run block.lvs # MATCH / MISMATCH + diagnostics $ vyges loom lvs run block.lvs --fail-on-mismatch # exit 3 — CI gate $ vyges loom lvs extract block.gds --rules sky130.rules --top block # GDS → SPICE ###### Open core · Apache-2.0 The comparator and the GDS extractor are open and runnable today. The per-foundry device-recognition decks (NDA) stay private. See all the engines & the data spine → ### vyges-drc Source: https://vyges.com/products/loom/drc/ Vyges Loom #### vyges-drc Geometric design-rule check — does the layout obey the foundry's rules? Width, spacing, area, density, antenna and enclosure on a GDS or OASIS layout — plus a metal-fill generator. Digital, analog and mixed-signal alike — geometry is technology-agnostic. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone taping out — and anyone who wants the geometry checked in seconds inside CI, not in a six-figure tool. A layout is only manufacturable if its geometry obeys the foundry's rules. `vyges-drc` is the geometric sibling of lvs — LVS asks does the layout implement the schematic?, DRC asks does it obey the rules? It checks six rule classes — width, spacing, area, windowed density, per-net antenna ratio, and enclosure — and, where a layer is too sparse, it generates metal fill to hit the density target and writes a filled GDS back out. It rides the same clean-room vyges-layout kernel `vyges-lvs` uses, so the physical-verification pair is one toolset, one language, one install. GDS + a `.drc` rule deck ──► vyges-drc ──► violations (text / JSON, CI exit code) ##### Describe the rules, not a script A small whitespace rule deck keyed on the GDS layer number — readable, diffable, schema-checkable — instead of a tool-specific rule language: `width 66 170 # min width on layer 66 space 68 140 # min spacing area 68 20000 # min polygon area density 68 20 70 100000 # coverage 20–70% per window connect 5 68 # layers connect where they overlap (via) antenna 68 5 400 # per net: conductor area ≤ 400 × gate area enclosure 68 66 40 # layer-66 shapes enclosed by layer-68 ≥ 40 fill 70 30 100000 600 400 # generate fill: top layer 70 to 30%` Antenna and enclosure bring connectivity and cross-layer checks, not just per-shape geometry. The reference deck ships for the open PDKs; the certified per-foundry deck stays private under the foundry's terms. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom drc demo # instant — built-in layout, all six rule classes $ vyges loom drc check block.gds --rules sky130.drc # violations report $ vyges loom drc check block.gds --rules sky130.drc --fail-on-violation # exit 3 — CI gate $ vyges loom drc fill block.gds --rules sky130.drc -o filled.gds # generate metal fill ###### Open core · Apache-2.0 The geometry engine is open and runnable today, with no foundry-confidential data — the rule deck is the plugin boundary. An open reference deck ships for the open PDKs; a certified per-foundry deck stays private. See all the engines & the data spine → ### vyges-cdc Source: https://vyges.com/products/loom/cdc/ Vyges Loom #### vyges-cdc Clock-domain-crossing check — the metastability bug a simulator can't see. Find every signal that crosses between unrelated clocks without a synchronizer, named and located. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone integrating IP across multiple clocks — where the bug shows up in silicon, not in the testbench. When a signal launched on one clock is captured by a flop on an unrelated clock, the capture can go metastable. That failure is invisible to a lockstep gate-level simulator — it samples one settled value per tick. Catching it is a purely structural graph question: `vyges-cdc` assigns each flop a clock domain by tracing its clock pin back to an SDC clock source, walks each capture flop's data cone to the flops that launch it, and reports every cross-domain crossing — flagging the ones that aren't a clean synchronizer. netlist + `.lib` + `.sdc` ──► vyges-cdc ──► crossings (OK / unsynchronized), CI exit code ##### A check simulation can't do Each `create_clock` in the SDC is a domain; the Liberty identifies the flops and their clock/data pins. A crossing is reported OK when it lands in a clean two-flop synchronizer, and a violation when there's no synchronizer — or when combinational logic sits on the crossing path, which a synchronizer must not have. It complements your simulator instead of competing with it: it surfaces exactly the failure class a cycle-based run steps over. Reads the same Liberty / Verilog / SDC the rest of Loom does. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom cdc check design.v --lib cells.lib --sdc design.sdc # crossings report $ vyges loom cdc check design.v --lib cells.lib --sdc design.sdc --json # machine-readable $ vyges loom cdc check design.v --lib cells.lib --sdc design.sdc --fail-on-violation # exit 3 — CI gate ###### Open core · Apache-2.0 A clean-room Rust engine, runnable today, on the same shared netlist / Liberty / SDC parsers as the rest of the suite. See all the engines & the data spine → ### vyges-glitch Source: https://vyges.com/products/loom/glitch/ Vyges Loom #### vyges-glitch Static glitch / hazard analysis — find where a signal can momentarily glitch before it settles. The reconvergent-fanout hazard a cycle-based simulator steps right over. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone whose design feeds an async path, a latch, or a clock gate — where a transient glitch becomes a real bug. When one signal reaches a gate's output by more than one path, those paths can disagree for a moment — and the output glitches before it settles. That is exactly what a lockstep gate-level simulator cannot see: it samples one settled value per tick and steps over the intermediate glitch. `vyges-glitch` catches it as a structural + timing question — it traces reconvergent fan-out and classifies each hazard static (paths of differing inversion parity) or dynamic (same parity, a delay-skewed settling window). netlist + `.lib` ──► vyges-glitch ──► hazards (static / dynamic, with the window), CI exit code ##### The blind spot of simulation Parity comes from each Liberty arc's unateness; the glitch window comes from the same delay tables sta-si times with. The analysis is a memoized traversal — polynomial in the design, never an exponential path walk — that finds the structural opportunity for a glitch a simulator is blind to. A clean complement to the simulators it's invisible to — on the same timing data your sign-off already produces. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom glitch check design.v --lib cells.lib # hazard report $ vyges loom glitch check design.v --lib cells.lib --json # machine-readable $ vyges loom glitch check design.v --lib cells.lib --fail-on-violation # exit 3 — CI gate ###### Open core · Apache-2.0 A clean-room Rust engine, runnable today, reading the same Liberty and netlists the rest of Loom does. See all the engines & the data spine → ### vyges-lec Source: https://vyges.com/products/loom/lec/ Vyges Loom #### vyges-lec Logic equivalence check — did that synthesis, ECO or hand-edit keep the logic the same? Prove two netlists compute the same function across all inputs — or get the one input where they differ. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone who edits a netlist after synthesis — an ECO, a clock-gate insertion, a hand-fix — and needs to know the logic still means the same thing. Every synthesis, ECO and hand-edit is a promise that the logic still means the same thing. Simulation can only spot-check that promise on the vectors you happened to run. `vyges-lec` proves it across all 2n inputs at once — or hands you the one input where the promise broke. It is the formal complement to simulation: it builds a canonical decision diagram for every output of both designs, so equal functions are provably equal, and a mismatch yields a concrete counter-example. golden.v + revised.v + `.lib` ──► vyges-lec ──► EQUIVALENT ✓ / NOT ✗ (+ counter-example) ##### Proof, not a sample It builds a canonical, reduced, ordered BDD for every endpoint of both designs over one shared variable order — so two functions are equal iff they share a node, and the check is exact rather than a sampled run. When they differ, the miter walks straight to a satisfying input. Sequential designs are cut at the registers — the standard combinational equivalence model. `vyges-lec — NOT EQUIVALENT ✗ (1 compared, 1 differ) differ at `f` when a=1 b=0` ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom lec check golden.v revised.v --lib cells.lib # verdict $ vyges loom lec check golden.v revised.v --lib cells.lib --json # machine-readable $ vyges loom lec check golden.v revised.v --lib cells.lib --fail-on-diff # exit 3 — CI gate ###### Open core · Apache-2.0 A clean-room Rust engine with an in-tree decision-diagram core — no external solver dependency — runnable today on the same Liberty / Verilog the rest of Loom reads. See all the engines & the data spine → ### vyges-gds-view Source: https://vyges.com/products/loom/gds-view/ Vyges Loom #### vyges-gds-view Headless GDS / OASIS layout viewer — render a layout to a layered SVG and overlay exactly where DRC or LVS flagged a problem. The where to the what, in any browser, no GUI to install. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone debugging a DRC/LVS failure in CI — where you need to see the spot, not just read a coordinate. drc and lvs tell you what is wrong with a layout. They don't show you where. `vyges-gds-view` closes that loop: render the GDS to a single self-contained SVG — every shape coloured by its layer, a legend, the Y axis the right way up — and drop the violation coordinates on top. Open it in any browser, commit it to a report, or diff it in CI. No display server, no GUI toolkit. GDS (+ violation marks) ──► vyges-gds-view ──► a layered SVG with the overlay ##### The visual companion to the geometry engines It rides the same vyges-layout kernel `vyges-drc` and `vyges-lvs` use, flattens the chosen top cell, and writes plain SVG text — so a DRC-then-look pass is two commands and a one-line glue. The marks file is the trivial `x0 y0 x1 y1 label` format any engine can emit. Analog & mixed-signal layouts too — it's pure geometry. A headless, mask-level renderer for reports and CI — not a GUI to babysit. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom gds-view demo -o demo.svg # instant — built-in layout → SVG $ vyges loom gds-view render block.gds -o block.svg # flatten top cell → SVG $ vyges loom gds-view render block.gds --marks viols.txt -o block.svg # overlay violations ###### Open core · Apache-2.0 A clean-room Rust renderer, runnable today, on the same geometry kernel the rest of the layout-side tools ride. See all the engines & the data spine → ### vyges-meas Source: https://vyges.com/products/loom/meas/ Vyges Loom #### vyges-meas Analog measurement you can defend — SNR, SINAD, THD, SFDR from a captured tone; gain, bandwidth, unity-gain frequency and phase margin from a sweep. Every number states the method that produced it, and refuses the inputs it cannot measure that way. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone signing off an ADC, DAC, PLL or amplifier from simulation or bench data — where the number goes in a datasheet and has to survive review. “SNR” on its own is not a measurement. The same capture, measured by two honest tools, can differ by several dB purely on convention: whether the fundamental bin is excluded from noise, how many harmonics are counted, whether DC is in the band, what happens to a harmonic that aliases onto another. `vyges-meas` does not implement “SNR” — it implements one closed method, states every choice it makes, and refuses a capture it cannot measure that way rather than returning a number that quietly means something else. captured tone / AC sweep ──► vyges-meas ──► SNR · SINAD · THD · SFDR · gain · BW · phase margin ##### A refusal is worth more than a wrong number A non-coherent capture, a clipped record, a harmonic that folds onto the fundamental — each one makes the standard arithmetic quietly wrong rather than obviously wrong. Most tools return a value anyway. This one names the problem and stops, because a spectral number you cannot trace back to its method is a number you will have to re-measure the week before tape-out. Nothing is extrapolated, either. If a sweep never crosses 0 dB inside its measured range, the unity-gain frequency is reported as not found — not invented from the trend. A sweep that stopped too early should read as a sweep that stopped too early. Nor will it infer what it was not told. A standard's scope depends on what the record came from — an ADC, a DAC, a recorder — and no list of numbers reveals that. So you declare it with `--application`, and until you do, the result does not reach for a standard's name. Guessing would manufacture a conformance claim out of nothing. Every result states how much it claims — a machine-readable alignment level. These are Vyges definitions, published and readable; they are deliberately not asserted as IEEE 1241 / 1658 / 1057 conformance, and the tool says so itself rather than leaving you to assume. ##### Try it The series is one sample per line in capture order, a power-of-two record, coherently sampled — `--fundamental-bin` says which bin the tone lands on. A sweep is `hz gain_db phase_deg` per line. $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom meas demo # instant — built-in coherent capture → the full metric set $ vyges loom meas spectral tone.series --fundamental-bin 16 --metric thd # harmonic distortion $ vyges loom meas spectral tone.series --fundamental-bin 16 --metric snr --target 60 # PASS/FAIL vs a spec $ vyges loom meas transfer ac.sweep --metric phase-margin # loop stability from a sweep Add `--json` for the machine payload, `--target` to turn a measurement into a pass/fail gate, or `--describe` to read the method itself. ###### Open core · Apache-2.0 A clean-room Rust kernel — a direct DFT, no third-party numerics in the trust path, so the definition can be read off the code. See all the engines & the data spine → ### vyges-ant Source: https://vyges.com/products/loom/ant/ Vyges Loom #### vyges-ant Find antenna violations before they become silicon failures. Check the routed database and get the exact gate and layer for every violation — including where the protection diode needs to go. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone taking a routed block to a foundry — antenna damage passes every simulation, survives every functional test, and turns up as yield loss. During fabrication, a long run of metal connected to a transistor gate acts as an antenna: it collects charge from the plasma etch and dumps it through the thin gate oxide. Too much metal per unit of gate area and the oxide is damaged — a device that passes every simulation and fails in silicon. The foundry states the limit as a set of ratios in the LEF, and the layout has to stay under them. `vyges-ant` checks them on the routed design database — all four forms (PAR, CAR, PSR, CSR), plain and diffusion-dependent, stage by stage as the metal stack is deposited. It does not just say a net failed: it names the gate, the layer, the value and the limit it broke. routed `.odb` ──► vyges-ant ──► antenna violations (gate · layer · value vs limit), CI exit code ##### A violation you can act on, not just a net name "Net `n1234` failed" does not tell you what to do. A protection diode goes on a specific gate, and the metal that damaged it was collected on a specific layer — so that is what the report names, along with the value and the limit it broke. That precision comes from charging metal to the gates on that piece of metal, rather than pooling a whole net together. Simpler models are why a checker either buries you in violations that are not real or, worse, hides ones that are. And when you disagree with the verdict, `explain` shows the working — gate by gate, stage by stage — instead of asking you to trust it. ##### The worst answer is a clean one you did not earn Foundries state antenna limits two different ways: as a constant per layer, or as a curve that rises with the diffusion connected to the net — which is exactly how a protection diode earns relief. A checker that reads only the first finds nothing at all on a technology that uses only the second, and reports a clean run. That is not hypothetical: sky130 states only the diffusion-dependent form. `vyges-ant` reads both. And where a technology states no limit for a ratio, it says so in the report rather than letting a clean verdict imply a check that never ran. It is cross-checked net-by-net against OpenROAD's `check_antennas` — agreeing on the net, the pin, the layer and the ratio — so you get a second opinion from a different implementation, in seconds, in CI. Keep `check_antennas` for sign-off; use this to stop shipping a block to it that was never going to pass. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom ant check design.odb # antenna report (JSON) $ vyges loom ant check design.odb -o antenna.json # write it to a file $ vyges loom ant explain design.odb --net net123 # why that net failed, gate by gate Exit status is the verdict: 0 clean · 1 violations · 2 error — so CI gates on the exit code without parsing prose. ##### Where it sits in the flow Timing is the whole point. Antenna is created by routing, and the routed database is the last stage where a violation is still cheap to fix — you insert a diode and re-route. Find it after stream-out and the answer arrives too late to act on. `vyges-ant` reads that database through vyges-opendb, so it runs where the fix still exists. It is the routing-stage counterpart to vyges-drc, which checks antenna geometry post-stream on a GDS. Same physical rule, two different stages — and the earlier one is the one you can still act on. ###### Open core · Apache-2.0 A clean-room Rust engine over the routed design database, reading the same foundry LEF rules the rest of the flow does. See all the engines & the data spine → --- ## Design optimization engines (open-core, Apache-2.0) ### vyges-resize Source: https://vyges.com/products/loom/resize/ Vyges Loom · Optimizer #### vyges-resize Gate sizing — pick a better drive strength for each cell to close setup timing or recover area. Where sign-off says what's wrong, this fixes it. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone closing timing on a synthesized or placed netlist — or trimming area/power once it's met. `vyges-resize` reads a netlist + Liberty + constraints and picks a better drive strength for each cell — upsizing cells on the critical path to close setup violations, downsizing cells with slack to recover area — then emits the resized netlist and a before/after timing report. The logic never changes; only the cell variant does. Every candidate is scored by the vyges-sta-si timer — it's pure Rust, so you can experiment with GPUs too via rust-gpu. It picks sizes, not locations: placement and routing stay the flow's job. netlist + `.lib` + constraints ──► vyges-resize ──► resized netlist + before/after timing ##### Pre-place, or post-place ECO Run it two ways: - · Pre-place on the synthesized netlist — size against ideal interconnect to enter place-and-route cleaner. A fast, cone-localized incremental timing pass scores each move. - · Post-place ECO — name a `spef:` and every candidate is scored against the real wire RC the placed design presents. That's where sizing earns its keep: the gate driving a long, heavily-loaded net is the one that actually needs the stronger variant. Exercised on real OpenROAD-routed sky130 with its extracted SPEF, and on built-in examples it closes a setup violation end-to-end. Sign-off is still the golden timer — `vyges-resize`'s numbers are a fast, license-free guide. ##### One declarative job A `.resize` file is a superset of a timing job: it adds the interchangeable cell families (weakest → strongest), the objective (`timing` or `area`), an effort budget, and `dont_touch` globs. Add a `spef:` for post-place ECO. The legal moves come entirely from your `.lib` — nothing foundry-confidential. Standard CLI: `--json`, `--quiet`, `--verbose`, and a `--fail-on-violation` exit code that gates CI. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom resize demo # instant — built-in example closes a setup violation, no setup $ vyges loom resize run top.resize -o sized.v # size → resized netlist $ vyges loom resize run top.resize --fail-on-violation # exit 3 if still violating — CI gate ###### Open core · Apache-2.0 Sizing is driven entirely by your Liberty — the legal variants and their delay/power — so `vyges-resize` carries no foundry-confidential data and runs out of the box on open PDKs. See all the engines & the data spine → ### vyges-vt-swap Source: https://vyges.com/products/loom/vt-swap/ Vyges Loom · Optimizer #### vyges-vt-swap Threshold-voltage swapping — trade a cell for a higher- or lower-Vt flavor of the same footprint to cut leakage while holding timing, or to close setup. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone with leakage budget to recover after timing closes — or a few stubborn paths to speed up. A higher-Vt flavor of a gate is slower but leaks far less; a lower-Vt flavor is faster but leakier. `vyges-vt-swap` is the sibling of vyges-resize — same idea, same timer-scored loop, but it trades threshold voltage (leakage/speed) rather than drive strength (area/speed). Two objectives, the inverse of each other: - · leakage (the headline): on a timing-met design, push every cell with positive slack to the highest-Vt, lowest-leakage flavor that still meets timing — free leakage recovery, the standard post-closure ECO. - · timing: drop critical-path cells to a faster (lower-Vt) flavor to close setup, then recover leakage on whatever slack remains. netlist + `.lib` + constraints ──► vyges-vt-swap ──► resized netlist + before/after timing & leakage ##### Same footprint, less leakage Because the swap keeps the same footprint, placement and routing are untouched — run it as a post-place ECO and hand the netlist back to the flow. It reports total cell leakage before and after (read from the `.lib`'s `cell_leakage_power`) alongside the timing it preserved; the built-in demo recovers a large share of leakage on a met design without moving WNS below zero. It's pure Rust — experiment with GPUs too via rust-gpu. Sign-off is still the golden timer — these numbers are a fast, license-free guide. ##### One declarative job A `.vtswap` file lists the iso-footprint Vt families fastest → slowest (low-Vt → high-Vt), the objective (`leakage` or `timing`), an effort budget, and `dont_touch` globs. Add a `spef:` to score against real interconnect. The legal flavors come entirely from your `.lib`. Standard CLI: `--json`, `--quiet`, `--verbose`, `--fail-on-violation` for CI. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom vt-swap demo # instant — built-in example recovers leakage, no setup $ vyges loom vt-swap run top.vtswap -o swapped.v # swap → resized netlist $ vyges loom vt-swap run top.vtswap --json # before/after timing + leakage ###### Open core · Apache-2.0 Swapping is driven entirely by your Liberty — the Vt flavors and their delay/leakage — so `vyges-vt-swap` carries no foundry-confidential data. See all the engines & the data spine → ### vyges-buffer-insert Source: https://vyges.com/products/loom/buffer-insert/ Vyges Loom · Optimizer #### vyges-buffer-insert Buffer insertion — when a net is so heavily loaded its driver's transition blows past the limit, split it: a fresh buffer takes over a share of the sinks so the driver switches faster. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone chasing a max-transition / slew violation on a high-fanout net. The third of the Loom optimizers, after resize and vt-swap. Those swap a cell for one with the same footprint; this one adds cells. `vyges-buffer-insert` finds the driver whose output transition most exceeds the limit, splits its net (a fresh buffer drives half the sinks, the driver keeps the rest), rebuilds the timer on the mutated netlist, and keeps the insertion if the worst transition dropped without breaking setup — repeating until every net is under the limit. netlist + `.lib` + constraints ──► vyges-buffer-insert ──► buffered netlist + before/after slew & timing ##### Structural, and honest about it Because inserting a buffer changes the netlist topology, each candidate is scored by a full timing build on the mutated netlist — correct, and bounded by the effort budget. A buffer costs a little delay, so on a met design the engine lets it consume slack as long as timing stays met; on a violating one it requires the move not to get worse. It is a pre-place structural fixup: it decides where in the logical net to split and hands placement of the new buffer back to the flow. The built-in demo relieves a four-fanout net's transition with one buffer while keeping timing met. Sign-off is still the golden timer — these numbers are a fast, license-free guide. ##### One declarative job A `.bufins` file names the `buffer:` cell to insert, a `max_slew:` transition limit, a `min_fanout:` threshold, an effort budget, and `dont_touch` globs. Add a `spef:` to score against real interconnect. Standard CLI: `--json`, `--quiet`, `--verbose`, `--fail-on-violation` for CI. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom buffer-insert demo # instant — built-in example relieves a heavy net, no setup $ vyges loom buffer-insert run top.bufins -o buffered.v # buffer → netlist $ vyges loom buffer-insert run top.bufins --json # before/after slew + timing ###### Open core · Apache-2.0 Driven entirely by your Liberty + constraints — no foundry-confidential data, runs out of the box on open PDKs. See all the engines & the data spine → ### vyges-hold-fix Source: https://vyges.com/products/loom/hold-fix/ Vyges Loom · Optimizer #### vyges-hold-fix Post-route hold-fix ECO — data reaching a capture flop too early? Insert a delay cell in series on the offending pin, deepening a chain only where hold stays negative, until the hold constraint is met. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone left with hold violations after detailed routing — the ones the setup-side ECOs can't touch. The hold counterpart to resize, vt-swap and buffer-insert — all of which fix the late / setup corner. Hold is the opposite problem: data arrives at a capture flop too early on the min-delay path. `vyges-hold-fix` reads the timer's per-endpoint hold slacks, inserts a delay cell in series on each hold-violating capture pin, grows a delay chain only where hold stays negative, and keeps a move only if the worst hold slack improved without pushing setup negative — so a slow clock's ample setup slack pays for hold closure, never the reverse. routed netlist + `.lib` + `.spef` + constraints ──► vyges-hold-fix ──► hold-fixed netlist + before/after WHS & WNS ##### A post-route ECO — scored on real parasitics Open place-and-route flows repair hold before detailed routing; the parasitics that detailed routing adds can then re-open it, with no later repair stage. `vyges-hold-fix` works after routing: with a `.spef` it scores against the real routed interconnect, targeting the residual hold the flow leaves behind. Each round is scored by a full timing build on the mutated netlist, and a move is kept only if worst hold improves and setup stays met. It decides which capture pins to delay and how deep a chain each needs; placement and routing of the inserted cells go back to the flow. The built-in demo closes a two-flop hold violation (worst hold slack −0.20 → +0.10 ns, met) with a short delay chain while setup stays met. Sign-off is still the golden timer — these numbers are a fast, license-free guide. ##### One declarative job A `.holdfix` file is a superset of a sta-si timing job — the same `design`/`netlist`/`lib`/`sdc`/`spef` keys — plus the hold knobs: the `buffer:` delay cell to insert, a `hold_margin:` target, `rounds:` (low/medium/high), and `dont_touch` globs. Standard CLI: `--json`, `--quiet`, `--verbose`, `--fail-on-violation` for CI. ##### Try it $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ vyges loom hold-fix demo # instant — built-in example closes a two-flop hold violation, no setup $ vyges loom hold-fix run top.holdfix -o fixed.v # delay → hold-fixed netlist $ vyges loom hold-fix run top.holdfix --json # before/after WHS + WNS ###### Open core · Apache-2.0 Driven entirely by your Liberty + constraints — no foundry-confidential data, runs out of the box on open PDKs. See all the engines & the data spine → ### vyges-remap Source: https://vyges.com/products/loom/remap/ Vyges Loom #### vyges-remap Multi-output technology re-mapping — recovers the area a one-output-at-a-time mapper leaves behind, and proves the function did not change before it hands the netlist on. Download All Loom engines View source on GitHub → ##### What it does Used by: anyone whose block is over its area budget after synthesis — particularly datapath, where the shared structure is the whole point. A conventional technology mapper covers one output at a time, so a cell that could have driven several outputs gets duplicated once per output. In arithmetic and datapath logic, where sub-expressions are shared everywhere, that duplication is a standing area tax. `vyges-remap` re-maps the same logic with a multi-output covering, then reports the before/after cell and area delta against a single-output baseline it computes itself — so the gain is measured, not asserted. mapped netlist ──► vyges-remap ──► smaller netlist + measured delta, equivalence-checked ##### An optimizer that has to prove itself Area is easy to win by accident and expensive to lose by accident. So a re-map is not trusted because the algorithm is sound — it is combinationally equivalence-checked against the input, and a re-map that changed the function is reported as such rather than written out. This is the same rule the rest of the suite runs on: the optimizers score every move against sta-si, and this one scores itself against a checker. It sits upstream of placement, at the logic level, where structural area is still cheap to change — the complement to the physical-side optimizers that work after the netlist is committed to a floorplan. Fewer cells before placement is smaller die, shorter wires, and less for every downstream engine to analyze. ##### Try it Bring your own logic tools. Unlike the rest of Loom, this engine is a driver: the mapping itself is done by mockturtle's `emap`, AIG extraction by Yosys, and the equivalence check by ABC. Point `$VYGES_EMAP`, `$VYGES_YOSYS` and `$VYGES_ABC` at your builds — `vyges install loom` does not supply them, and `vyges-remap` will tell you which one it could not find rather than proceeding without it. $ vyges install loom # one-time: fetch the Loom suite into ~/.vyges/bin $ export VYGES_EMAP=/path/to/emap VYGES_YOSYS=$(which yosys) VYGES_ABC=$(which abc) $ vyges loom remap emap --verilog block.v --top block --liberty sky130.lib -o block_remapped.v $ vyges loom remap emap --aig block.aig --genlib cells.genlib --json # machine payload The equivalence check runs by default; `--no-cec` skips it, and says so in the result. ###### Open core · Apache-2.0 A Rust driver over open logic-synthesis research, wearing the same result envelope as every other engine. See all the engines & the data spine → --- ## Products & platform ### Vyges CLI Source: https://vyges.com/products/vyges-cli/ Free developer tooling we share with the community. The product we sell is silicon. Vyges Toolchain #### Vyges CLI™ One command-line front door to the Vyges hardware-IP toolchain — find & fetch verified silicon IP, present & resolve PDKs, and install & run the open Vyges Loom sign-off & optimization engines — the way `npm` fetches packages or `pip` fetches wheels. Free, and built in Rust. Download Read the docs One free prebuilt binary · macOS · Linux · Windows ##### What it does For: IP developers, platform teams, and CI/agent workflows that need silicon IP and PDK collateral on the command line. `vyges` is the single entry point to the Vyges toolchain. It promotes a small, curated set of tools and dispatches git-style to external `vyges-` binaries on your `PATH` — so one install gives you the whole suite. It leads with catalog (find and fetch verified silicon IP) and pdk-store (present and resolve PDKs consistently across fabs), and `vyges install loom` fetches the open Vyges Loom suite — the sign-off and optimization engines (characterization, extraction, timing, power, power-integrity, LVS; plus gate sizing, Vt-swap, buffer insertion) — each runnable as `vyges loom ` or just `vyges `. One free, prebuilt binary; `--json` on every command makes it as comfortable in CI and AI agents as in a terminal. vyges ──► catalog (search · fetch IP) + pdk-store (present · resolve PDKs) + loom (install · run sign-off & optimization engines) ##### A package manager for silicon — the PDKs, and the sign-off & optimization engines ###### Find & fetch IP Search-first discovery (no bulk dumps) across an open `oss` catalog plus any enterprise or NDA sources you add. Fetch an open — or private — IP and it materializes into `~/.vyges/catalog/`, ready for your flow. `vyges catalog search · show · fetch` ###### Present & resolve PDKs One consistent surface over Ciel, git-mirrored, NDA, and customer PDKs. `use` a PDK, then `resolve` collateral paths — tech LEF, DRC/LVS decks, `.lib` per corner, GDS — so flows stop hard-coding fab paths. `vyges pdk-store use · resolve · list` ###### Scriptable & agent-ready One binary on macOS, Linux, and Windows, with `--json` on every command and `-q`/`-v` logging. `vyges modules` and `vyges agents` serve humans and AI IDE agents alike; bugs, features, and sponsorship are one flag away. `vyges modules · agents · --json` ###### Install the Loom engines `vyges install loom` fetches the open Vyges Loom suite on demand — sign-off (timing, extraction, characterization, power, LVS) and optimization (resize, vt-swap, buffer-insert). Run any engine as `vyges loom `; each ships a zero-setup `demo`. `vyges install loom · vyges loom ` ##### Install Prebuilt binaries — one release bundles `vyges`, `vyges-pdk-store`, and `vyges-catalog` into `~/.vyges/bin`. The Loom engines are fetched on demand with `vyges install loom`. # Homebrew (macOS / Linux) $ brew install vyges/tap/vyges # or the curl installer $ curl --proto '=https' --tlsv1.2 -LsSf https://github.com/vyges-tools/cli/releases/latest/download/vyges-installer.sh | sh # or on Windows (PowerShell) PS> irm https://github.com/vyges-tools/cli/releases/latest/download/vyges-installer.ps1 | iex # binaries land in ~/.vyges/bin — add to PATH if needed $ export PATH="$HOME/.vyges/bin:$PATH" $ vyges --version $ vyges modules # which Vyges modules are installed $ vyges install loom # fetch the open Loom sign-off & optimization engines ##### Try it $ vyges catalog search uart # find IP (search-first) $ vyges catalog fetch uart-controller # → ~/.vyges/catalog/ip/… $ vyges pdk-store use sky130A # select a PDK $ vyges pdk-store resolve sky130A drc_deck # collateral path for your flow $ vyges install loom # then run any engine… $ vyges loom sta-si demo # timing sign-off on a built-in design $ vyges loom resize demo # gate-sizing optimizer on a built-in design ##### It also hands these tools to your AI assistant The same binary ships `vyges mcp` — a local Model Context Protocol server. One command and every engine on your machine becomes a tool that Claude Code, Cursor or VS Code can actually run, with your design never leaving your hardware. $ vyges mcp setup # register with the AI IDEs installed here $ vyges mcp --list # see exactly what it would advertise How vyges mcp works → ##### Full documentation Installation, output & logging, and a complete command reference for `vyges`, `pdk-store`, `catalog`, and the Loom engines — generated from each tool's own `--help`, so it never drifts. Read the docs ##### Download Vyges CLI One free, prebuilt binary — macOS, Linux, and Windows. The Loom sign-off & optimization engines are a `vyges install loom` away. Download & install Releases on GitHub ### Vyges MCP Source: https://vyges.com/products/mcp/ Vyges MCP™ #### Give your AI assistant hands for silicon design. One local MCP server turns the silicon tools on your machine into callable, typed tools — so your assistant can actually run sign-off, timing, DRC, LVS, synthesis, and place & route. No port. No auth. No cloud. Get the CLI See an agent drive it Ships inside the Vyges CLI — nothing extra to install. Local by design No port No auth No cloud No upload The server speaks JSON-RPC over stdin and stdout to a process your own client starts. The engines are binaries on your disk reading files on your disk — which is what makes this usable against a PDK under NDA and IP you cannot send anywhere. ##### Your assistant can discuss DRC. It cannot run one. Every model will happily explain antenna rules, argue about hold margin, and write you a Tcl script it cannot execute. The gap is not knowledge. It is execution. Meanwhile the tools that do the real work sit on your disk behind a dozen different command lines, each with its own flags, file formats, and idea of what an error looks like. `vyges mcp` is a local Model Context Protocol server that closes it. Run it once and every engine it resolves on your machine becomes a callable tool with a typed contract — so you ask in plain English, the model picks the right engine and the right arguments, and a deterministic binary does the actual work. your words ──► your model ──► vyges mcp ──► real engines on your hardware ──► a result, not a guess ##### No fine-tuning. The tools explain themselves. This is the part that makes it work. There is no Vyges-specific model and no prompt library you have to keep in step with our releases. Every engine ships a machine-readable contract — `--describe` — stating what it consumes, what it produces, and what its results mean. That description is the integration: the model reads it at connect time and routes from it, and it travels with the binary, so it cannot drift out of date. Which makes bring your own model real rather than aspirational. If it can call MCP tools, it can drive the engines — hosted, open-weight, or domain-specific. ###### We publish the proof, not just the claim An agent is handed plain-English requests on a clean GitHub Actions runner, with nothing but the engines' own descriptions to work from, and has to choose the tools itself. The run report shows what it picked and what came back — read the latest one → ##### One interface across the open silicon stack It is not only the Vyges engines. The open tools you already run are exposed through the same interface, so your assistant does not need to learn six invocation styles to get through a flow. ###### The Vyges Loom engines Timing and signal integrity, DRC, LVS, extraction, power, IR-drop and electromigration, thermal, CDC, glitch, equivalence, characterization, layout rendering, analog measurement — plus the optimizers that act on what they find. ###### The open tools beside them OpenROAD, Yosys, Magic, Netgen, KLayout and Verilator are exposed as passthrough tools — the underlying tool stays in control of execution, with your arguments handed to it directly. Ask `vyges mcp tools` what resolved on your host — it reports what it found and what it could not, rather than advertising tools that are not there. ##### Analyze freely. Mutate deliberately. Reading your design and rewriting your netlist are not the same risk, so they are not the same permission. Every tool is classified by what it does to your design — and the classification is derived from the engine's own description, not a list someone maintains by hand, so it cannot drift away from what the binary does. Read ###### Look, measure, report DRC, LVS, timing, extraction, power, thermal, CDC, glitch, equivalence, measurement. They produce findings. They never touch the design. Mutate ###### Change the design The optimizers, the re-mapper, and every external tool that could write. Anything not provably read-only lands here — least privilege, deliberately. Profiles ###### `core` · `pro` · `full` `core` exposes the read-only tools only — the agent can analyze all day and cannot alter anything. `pro` and `full` admit the mutating tools. Which profile you get: the default is `full`, so that adding the gate did not change what already worked for existing users. Restricting the surface is one environment variable — `VYGES_MCP_PROFILE=core` — and that is what we would run when pointing an agent at a design that matters. ###### Running this across a team? Where the line falls is a policy question, and it is rarely the same twice — analysis-only for contractors, mutation behind review for the ECO team, particular tools withheld entirely. Because the classification comes from the tools' own descriptions, the boundary is configuration rather than a fork. Talk to us about a profile that matches your policy → The model is a driver, never a computation. Pull it out and the same engines run headless in CI, producing the same answers. ##### Install once. Then just ask. $ vyges install loom # fetch the engines $ vyges mcp setup # find your AI IDEs and register with each of them # then, in Claude Code / Cursor / VS Code: "run DRC on this GDS against the sky130 deck installed locally" "why is this path failing setup, and what would fix it?" `vyges mcp --list` prints exactly what the server would advertise, before you connect anything to it. ##### What actually reaches the model Worth being precise, because "local" is easy to overstate. The MCP server does not upload your design or your PDK to a Vyges service — there is no Vyges endpoint in the path at all. What your model sees is whatever your AI client sends it: your prompts, the tool descriptions, and the results and paths the tools return. That traffic is governed by the client and model you configure — a local model keeps it on the machine, a hosted one does not. Choosing that is yours, and the `core` profile bounds what an agent can do with it either way. ###### Where it fits your AI IDE ─► vyges mcp ─► Loom engines + open tools ─► your PDK & your design The reasoning is rented and replaceable. The engines, the data, and the answers are yours. Install the Vyges CLI Talk to us about your flow The design rationale is written up in our papers — deterministic core, agent tail → ### VyBox Source: https://vyges.com/products/vybox/ Free developer tooling we share with the community. The product we sell is silicon. #### VyBox™ Developer Infrastructure in a Box Spin up a complete, self-contained development environment — preloaded with Git-based version control, a browser-accessible IDE, and all Vyges tools for building, testing, and publishing silicon IP. Launch VyBox Lite VyBox EDA ##### Everything You Need for Silicon IP Development VyBox delivers a complete, all-in-one development environment equipped with every tool and infrastructure you need for modern silicon IP creation. ###### Self-Contained Environment Git-based version control, a browser-accessible IDE, Vyges tooling, and built-in CI/CD pipelines (GitHub Actions, GitLab CI) — all packaged in a single Docker container. ###### Pre-Installed Tools Open source RTL development, testing, verification, synthesis, and simulation tools—ready to go, from RTL to GDSII. ###### AI-Assisted Development Bring your own LLM keys. Seamless integration with major LLM providers and AI coding assistants to supercharge your workflow. ###### VyBox Lite A cloud IDE for silicon IP, launched in your browser via GitHub Codespaces Free - Browser-based dev environment via GitHub Codespaces - Pre-installed open-source EDA tools — RTL to GDSII - Bring-your-own-LLM keys; works with any AI coding assistant - Community support Launch VyBox Lite ###### VyBox EDA The open RTL→GDSII toolchain as a single container — runs anywhere Free - From-source Yosys, OpenROAD, ngspice, KLayout — plus Magic & Netgen - IHP SG13 PDKs bundled (sg13g2 + sg13cmos5l) — digital, analog & mixed-signal; sky130 / gf180 on demand - Clean-room & auditable — built from source, runs on free CI - `docker pull ghcr.io/vyges-tools/vybox-eda` · linux/amd64 Get VyBox EDA ###### VyBox Enterprise What we figure out together Custom engagement - What AI model, tools, and methodology best suit your organization and workflow - LLM strategy — commercial (AWS Bedrock, Azure OpenAI), in-house, hybrid, or air-gapped - Internal training — fine-tuning, retrieval augmentation, where the data lives - Authentication, identity, and deployment topology — Enterprise SSO, on-prem, VPC, air-gapped Start the conversation Early Access · in development ###### VyBox-Sley The end-to-end sign-off flow: the Vyges open sign-off engines orchestrated RTL→GDSII in one container — with timing, power, IR/EM, and LVS built into the flow, not bolted on after. OpenROAD / Yosys / KLayout stay the commodity place-and-route steps; sign-off is the Vyges layer on top. - ✓ Commercial-grade sign-off engines, orchestrated end-to-end - ✓ Reproducible & CI-native — one container, plain files - ✓ OpenROAD / Yosys / KLayout as commodity steps - ✓ Per-foundry accuracy via gated calibration plugins Want it early? Tell us about your flow and we'll bring you into the program as it lands. Request Early Access See the engines it runs → ### VyCatalog Source: https://vyges.com/products/vycatalog/ #### The first open registry for silicon IP 150+ IPs indexed and growing Software has PyPI, npm, and Crates.io. Until VyCatalog™, silicon had nothing equivalent. See the nutrition label format A proprietary registry would cap supply; an open one compounds it. VyCatalog supports both open and private catalogs — the public registry defines the open silicon metadata standard, and private catalogs let enterprises apply that same standard to their own proprietary, embargoed, or licensed IP. One engine, one metadata model, two configurations. The Vyges Metadata Standard turns the spreadsheet into a code artifact — registers, parameters, and interfaces version-controlled with the RTL, not maintained as separate spec docs. ##### IP Nutrition Labels & Catalogs You wouldn't open every cereal box at the grocery store and taste it before buying. You read the label. Today, "tasting" silicon IP means reading the RTL — every interface, every register, every state machine. Engineers need (System)Verilog fluency to read and understand. AI tools burn tokens parsing it from scratch every time. Labels avoid both costs. VyCatalog gives every IP block a standardized IP Nutrition Label: bus, registers, timing, integrity status, license, target PDK — all scannable in seconds. The label normalizes across IPs the same way an FDA food label normalizes "salt" vs "sodium bicarbonate" — different underlying source, one readable surface. Engineers scan it; AI agents consume it directly. Scroll down, click any IP in the catalog to see a real label. For the underlying schema, see the Vyges Metadata Standard. ##### IP Catalog Live Browse real IP entries from the VyCatalog™ public registry. Each block is described using a standardized, machine-readable nutrition label designed for both engineers and AI agents. List View Directory View ###### All IP Blocks ###### Welcome to VyCatalog Select a category from the directory to browse IP blocks, or click on an IP to view its details. Loading IP catalog... ##### Why VyCatalog? The first discoverable registry of verified, composable hardware IP blocks with standardized metadata and quality assurance. ###### Verified Quality All IP blocks undergo quality assurance and compliance checking with standardized metadata validation. ###### Discoverable Search and filter IP blocks by category, license, target technology, and design type with rich metadata. ###### Composable Standardized interfaces and metadata enable seamless integration and composition of IP blocks. ##### VyCatalog for the enterprise Same engine as the open registry — applied to proprietary, embargoed, and licensed IP. ###### How it scales for enterprises The public registry and the private catalogs we operate for buyers run on the same engine. The open catalog scale-tests the enterprise deployment; fixes flow in both directions; there is no fork. ###### Deployment options Private catalogs can be deployed on-premise, in your own cloud, or as a Vyges-managed deployment — your choice. The same engine runs in all three; only the operator differs. ###### Where it fits VyCatalog Enterprise sits where established enterprise IPLM (Perforce IPLM, Siemens) and emerging cloud-platform marketplaces (ChipFoundry) leave gaps: silicon-native and AI-native rather than retrofitted PLM; source-controlled metadata standard rather than server-configured per-instance schema; customer-deployed (on-premise, your cloud, or Vyges-managed) rather than cloud-upload-only; multi-target (ASIC, FPGA, chiplet) rather than ASIC-only. ##### Built for AI-assisted IP workflows Machine-readable metadata is cheap to query and context-cheap to keep loaded. Navigating thousands of IP repositories — many of them archived — costs engineering hours and, increasingly, real LLM tokens. Every time an AI assistant greps raw RTL to answer a question the metadata could have answered, you pay twice: once for the tokens, once for the context window the irrelevant code occupied. The Vyges Metadata Standard lets agents read the structured fact first and the code only when the question demands it. An AI agent can audit a 10,000-IP estate without loading every archived RTL line into context. Token cost stays bounded; context windows go further; the answer arrives faster. ##### Organized by Function IP blocks are categorized by their primary function, making it easy to find the right component for your design. ###### Category Structure 📁 IP Catalog/ ├── 📁 Interface Controllers/ ├── Serial Interfaces ├── Parallel Interfaces └── Protocol Controllers ├── 📁 Arithmetic Units/ ├── Adders & Subtractors ├── Multipliers └── ALUs ├── 📁 Memory Subsystems/ ├── Controllers ├── Interfaces └── Caches ├── 📁 Converters/ ├── ADC ├── DAC └── Level Shifters ├── 📁 Signal Processing/ ├── FFT ├── Filters └── DSP Cores └── 📁 Security IP/ ├── Crypto Engines ├── Authentication └── Key Management ###### Key Features ###### Hierarchical Organization Browse by function, then drill down to specific IP types and implementations ###### Rich Metadata Each IP includes detailed specifications, licensing, and integration guides ###### Quality Assurance All IP blocks are verified for compliance and functionality ###### Easy Integration Standardized interfaces and documentation for seamless design integration ###### For Engineers ##### Start building with verified IP Browse the live catalog, inspect metadata nutrition labels, and integrate IP into your SoC flow. Browse Catalog Metadata Spec ###### For Decision-Makers ##### Replace spreadsheets with a system of record VyCatalog replaces internal IP tracking spreadsheets with a searchable, version-controlled registry that both engineers and AI agents can query. Talk to Us Enterprise Deployment ### VyContext Source: https://vyges.com/products/vycontext/ #### Internal Development Infrastructure We Share VyContext™ enforces Vyges' IP-development standards inside the IDE. It exists to support our silicon products — not as a commercial tool. VS Code Extension Cursor / Open VSX Also supports Claude Code (CLI) — one-line `claude mcp add` setup. Requirements: VyContext requires installing the IDE extension (VS Code or Cursor) and a GitHub or Google account login. This delivers your context securely and ties the extension to your identity. ##### Transform Your Silicon Development Process VyContext makes your methodology system-enforced, not individually remembered. Reduce onboarding time, increase IP reuse, prevent costly late-stage integration failures, and transform your engineering organization into a continuous innovation engine — safely. Instant Time to value Instant Onboarding time (vs. months) ≥30% Reduction in review time 100% Methodology compliance ##### Solve Your Team's Biggest Pain Points Common challenges in silicon IP development — and how VyContext solves them. Problem VyContext Solution Outcome New engineers take months to onboard. They ask teammates for examples, search through tribal knowledge, and make mistakes that delay projects. AI IDE-native templates and metadata-driven catalogs provide instant access to standardized patterns. No searching, no asking — everything is right in your AI IDE. Onboarding time cut from months to days — instant access to your team's best practices. AI tools generate non-compliant code. Engineers waste time fixing naming conventions, directory structures, and methodology violations in code reviews. Automatic methodology enforcement in IDE ensures AI-generated code adheres to your rules — naming, directory structures, checklists, package formats. Reduce review cycles by 30% — AI-generated code is compliant from the start. IP reuse is tribal knowledge. Teams duplicate work, miss existing IP blocks, and face costly late-stage integration failures when incompatible IP is integrated. Metadata-driven discovery & reuse with catalog integration. Find compatible IP blocks instantly, understand dependencies, and ensure consistent standards across teams and vendors. 100% methodology compliance — prevent costly integration failures before they happen. Compliance issues and security concerns prevent teams from using AI tools. Data residency requirements, audit trails, and enterprise security standards block adoption. HTTPS GET only — no data sent to Vyges. Works with any LLM (AWS Bedrock, Azure OpenAI, on-prem). VPC/on-prem data residency by default. Google/GitHub login or Enterprise SSO. Secure & compliant workflow — use AI tools without compromising security or compliance standards. ##### Key Capabilities Benefits you get, features that deliver them. ###### Instant Onboarding Benefit: New engineers become productive immediately, not after months of training. Features: IDE-native templates, metadata-driven catalogs, standardized patterns available instantly in your IDE. ###### Consistent IP Standards Benefit: Consistent IP standards across teams & vendors — no more integration surprises. Features: Enforced naming, directory structures, checklists, package formats. Automatic methodology enforcement in IDE. ###### Secure & Compliant Workflow Benefit: Use AI tools without compromising security or compliance standards. Features: HTTPS GET only; no data sent to Vyges. Works with any LLM (AWS Bedrock, Azure OpenAI, on-prem). VPC/on-prem data residency by default. ###### Ready-to-Use Silicon Context Benefit: Out-of-box context for silicon development — no manual setup or configuration. Features: RTL & SoC design patterns, verification (UVM, cocotb, SVAs), physical implementation (UPF, timing closure), metadata-driven discovery & reuse. ###### Flexible for Any LLM / EDA Flow Benefit: Works with your existing infrastructure and tools — no vendor lock-in. Features: Works with AWS Bedrock, Azure OpenAI, on-prem LLMs. VS Code, Cursor, JetBrains support. No manual prompting or external docs. ##### Trusted by Silicon Experts See what early adopters are saying about VyContext "I used the Vyges AI platform to generate RTL for a Stanford-based 32-bit RISC processor with a 5-stage pipeline, interrupts, branch prediction, and later a full 32-bit multiplier with hazard detection. I described the spec entirely in plain English, and the platform asked for clarifications only when needed. Vyges generated the full repository—architecture docs, RTL, testbench, and files—cleanly organized and cross-referenced. The RTL quality was excellent: modular, readable, and comparable to what an expert team would build. Even the gate-count estimate (TSMC 22 nm) matched our prior silicon results. Overall, Vyges dramatically accelerates chip-design productivity if you know what you want." Read full testimonial "I used the Vyges AI-based platform to design RTL for a Stanford-derived 32-bit RISC processor. The initial spec included a 5-stage pipeline, aligned memory accesses, NMI + four interrupts, and simple branch prediction. We later expanded the spec to include a complex 32-bit multiplier with overflow, pipeline stalls, and hazard-detection logic. I wrote the entire spec in plain English. The platform only asked for clarification where needed, and the whole process took minutes. Vyges then generated a complete project repository—architecture docs, RTL, testbench, collateral—neatly structured and cross-referenced. The RTL quality genuinely surprised me. It was modular, logically partitioned, and well-commented—exactly the kind of work you'd expect from a highly experienced engineer. Even the gate-level estimate for a 22 nm TSMC node was accurate (≈50k gates, including a 10k-gate multiplier), matching our past silicon. Overall, the Vyges platform is impressive. With a clear idea of what you want to build, it massively boosts chip-design productivity." Kumar Hebbalalu Silicon Expert ##### Ready to Transform Your Silicon Development? VyContext transforms your engineering organization into a continuous, compliant innovation engine — enabling AI-powered development inside your IDE without compromising methodology, quality, or security. Discuss a silicon engagement Install Extension VS Code Cursor ### VySeal Source: https://vyges.com/products/vyseal/ Vyges · Security & Licensing #### VySeal™ Cryptographic signing, encryption, and licensing for silicon IP — protect, prove, and deliver designs across vendor tools, without locking them inside one EDA walled garden. Request Early Access All Vyges Products Early access · closed-source binaries (request access below) ##### What it does For: IP publishers, silicon vendors, and platform teams that distribute designs to customers or across EDA toolchains. `vyseal` is the security and licensing layer of the Vyges ecosystem — a CLI (and library) that signs, verifies, encrypts, and licenses silicon IP. It gives a design a tamper-evident identity (Ed25519 signature over a SHA-256 Merkle tree) and standards-based encryption (IEEE P1735) that the major EDA tools read directly — so IP stays portable and provable instead of trapped behind a single vendor's proprietary delivery format. VySeal complements — not replaces — EDA tool encryption, license servers, and foundry NDAs, by making IP packages independently verifiable and portable. It operates at the artifact and package layer; it does not inspect, modify, or interpret the functional behavior of the IP itself. IP + keys ──► vyseal ──► signed (+ optionally P1735-encrypted) package + `vyseal-manifest.json` ##### Four cryptographic operations on one sealed manifest ###### Signing & integrity Ed25519 signatures over a SHA-256 Merkle tree produce a `vyseal-manifest.json` with per-file hashes — any later tampering is detectable down to the single file. `vyseal sign` · `vyseal verify` ###### IEEE P1735 encryption Standards-compliant RTL/gate-level encryption with per-recipient key wrapping compatible with the major EDA toolchains — without re-authoring the IP per vendor — plus a native AES-256-GCM mode for Vyges-to-Vyges delivery. `vyseal encrypt --to synopsys,cadence,siemens` ###### Keys, trust & license binding An Ed25519 keystore you control — generate, list, back up, and restore — with trust-on-first-use or a pinned public key to authenticate a publisher. The IP's license and metadata are sealed into the manifest, so they travel cryptographically bound to the package. VySeal adds no runtime call-home checks or tool-dependent enforcement. `vyseal keygen` · `vyseal keys` ##### The workflow A publisher seals an IP once; any consumer can verify it, and encrypted deliveries open only in the tools they were wrapped for. Consumers verify sealed IP independently — no shared trust anchor with Vyges or an EDA vendor is required. Early-access partners get the `vyseal` binary. $ vyseal keygen # one-time: Ed25519 key pair in ~/.vyseal/keys/ $ vyseal sign ./my-ip/ # hash + Merkle tree + sign → vyseal-manifest.json $ vyseal encrypt ./my-ip/ --to synopsys,cadence,siemens # P1735 per recipient $ vyseal verify ./my-ip/ # signature + Merkle + per-file hashes $ vyseal keys list # manage the ~/.vyseal keystore (list / backup / restore) ##### Early Access VySeal ships as a closed-source binary to early-access partners. Tell us about your IP and delivery needs — requests are private and tracked individually, not posted to a public forum. Ideal for teams distributing RTL, netlists, or IP bundles across multiple customers, vendors, or toolchains. Request Early Access Prefer to talk first? Contact us → ### VyShuttle Source: https://vyges.com/products/vyshuttle/ #### VyShuttle™ From verified IP to silicon — your launchpad to fab. Coming Soon ##### Developer-Friendly Silicon Launchpad Like CI/CD for Silicon — from IP to tapeout with batch manufacturing built in. ###### Build & Validate Design IP with RTL and metadata, then validate it with automated checks. ###### Bundle & Submit Generate tapeout-ready GDSII and submit via API or CLI ###### Track & Monitor Follow your submission through the shuttle queue, fab stages, and test results. ##### Seamless VyBox Integration VyBox serves as your personal dev environment for local simulation, metadata validation, and shuttle submission—no extra setup needed. ###### Complete Local Development - Build IP, validate it, simulate test cases locally - Optional version control integration for collaborative development - Metadata-driven validation and shuttle preparation ###### Workflow Steps 1 Build & validate IP blocks 2 Bundle for test chip integration 3 Submit to VyShuttle via API/CLI 4 Track shuttle queue and timeline ##### Ready to Launch Your Silicon? Join the community of developers bringing their IP to silicon through VyShuttle. Try VyBox Get Started ### Post-silicon Source: https://vyges.com/products/post-silicon/ #### Bring your IP to life Evaluation kits and dev boards for real-world testing, demos, and productization. Learn More View Boards ##### From Silicon to System Take your IP from simulation to system. Our dev boards and kits let you test, validate, and demo your silicon in the real world. ###### Development Boards Ready-to-use boards featuring your IP blocks for rapid prototyping and testing. ###### Evaluation Kits Complete evaluation kits with software, documentation, and example applications. ###### Documentation Comprehensive documentation, schematics, and reference designs for each board. ##### Choose Your Development Platform Choose the right development platform for your IP evaluation and system integration needs. ###### FPGA Boards — Reprogrammable, Fast Iteration Rapidly prototype and validate your IP on FPGA platforms before silicon tapeout. - Major FPGA platforms - Pre-configured IP blocks - Bitstream generation and deployment - Performance benchmarking tools Best for: IP validation, performance testing, early customer evaluation ###### ASIC Boards — Final Silicon, Ready to Demo Production-ready evaluation boards featuring your taped-out IP in silicon. - Custom ASIC integration - Production performance characteristics - Real-world testing and validation - Customer demonstration and sales Best for: Final validation, customer demos, production qualification ##### Seamless Integration Our development boards integrate seamlessly with the Vyges ecosystem and your existing workflows. We’re working with early partners to shape the first batch — be a part of it. ###### VyBox™ Integration Direct integration with VyBox for automated board programming and testing. ###### CLI Support Vyges CLI™ commands for board management, programming, and testing. ###### Open Source Open-source schematics, layouts, and firmware for complete transparency. ###### Performance Optimized for maximum performance and real-world testing scenarios. ##### Coming Soon Our first development boards are in design. Sign up to be notified when they're available. Get Notified Try VyBox ### Free Tools Source: https://vyges.com/tools/ #### Free Tools Browser-based tools for silicon IP and chip design — no login, no license, no install. Small, focused tools that solve one problem well. Built in the open, free to use, and part of how we ship AI-native silicon engineering. ##### Available now Everything here runs free in your browser. ###### Compliance Checker Check any IP repository against the Vyges Metadata Specification and get a quality score with actionable fixes. Open tool → ###### Chip Viewer Pan and zoom real taped-out silicon layouts right in the browser — explore floorplans and macro placement interactively. Open tool → ###### VyCatalog IP Search Discover and explore 150+ verified, machine-readable silicon IP blocks — each with an FDA-style IP Nutrition Label. Browse IP → ###### Metadata Spec Explorer Read the validated JSON Schema that describes reusable silicon IP — interfaces, registers, parameters, PDKs, and licensing. View spec → ###### PDK Descriptor Standard One neutral descriptor schema over heterogeneous PDKs, 180 nm → 2 nm — a single presentation contract for process data. View standard → ##### In development Tools we're building next. Want one sooner? Tell us. Coming soon ###### Tape-out Cost Estimator Sketch a die size and PDK, get a ballpark MPW shuttle estimate before you commit. Coming soon ###### Register-Map Generator Describe a peripheral's registers and export clean docs and RTL stubs. Coming soon ###### Liberty & SPEF Viewer Drop in a `.lib` or SPEF file and inspect timing arcs and parasitics in the browser. Free · one binary ##### Prefer the terminal? Get the Vyges CLI The Vyges CLI is the command-line front door — like `npm` or `pip` for silicon. Find & fetch verified IP from the catalog (`vyges catalog`), resolve & install PDK collateral (`vyges pdk-store`), and add the sign-off engines with `vyges install loom`. Free, Rust, `--json` on every command. Get the CLI → Open-source · Apache-2.0 ##### Looking for the sign-off engines? The browser tools above are the front door. Vyges Loom is the full suite of commercial-grade EDA sign-off engines — timing with signal integrity, parasitic extraction, power, EM/IR, thermal, LVS, and the optimizers that close the loop. Free and open, installed via the CLI (`vyges install loom`), driven by declarative job files, CI-native — and drivable by any AI model locally through `vyges mcp`. Explore Loom → ##### Build with the full platform These tools are the front door. The CLI, registry, and open EDA sign-off engines are where teams ship real silicon. Explore Products Talk to Us Questions, or found a bug? Join the discussion on GitHub → --- ## Silicon & technology ### Silicon Source: https://vyges.com/silicon/ #### Silicon Silicon is not a category we serve — we are a silicon company. Most silicon programs spend millions and 6–9 months outsourcing integration just to reach tapeout. Vyges replaces that step with fab-ready SoC IP (System-on-Chip IP) — integrated, verified, and deliverable in weeks. Talk to us about silicon ##### The wedge — fab-ready SoC IP Vyges sells fab-ready SoC IP — complete, integrated, and proven — so companies don't have to spend millions and 6–9 months outsourcing integration just to get to tapeout. Legacy: Outsourced Integration Vyges: Fab-Ready SoC IP Inputs Buy multiple commercial IPs; mix open + proprietary blocks Select a fully built SoC IP from VyCatalog, or commission one from known reusable blocks Process Contract an external integration house, long SOW negotiation, manual RTL integration, bespoke verification, ad-hoc docs, hand-offs between teams Pre-integrated, verified, metadata-complete SoC; hardened macros; known PDK targets; CI-verified build → sign → package → synthesize Time 6–9 months minimum Weeks Cost $2–5M+ before first silicon Order-of-magnitude reduction Fab ownership Integration vendor owns it Vyges can take it to the fab; deliverables are fab-ready on day one Reuse next time Limited — bespoke output Versioned, registered, composable for the next program Vyges sells productized silicon artifacts, not labor or scoped design services. Fab-ready integration delivered in weeks — not units licensed or engineer-hours billed. Engagement scoped to your requirements. ###### What "weeks" means Typical engagements deliver a fab-ready, signoff-clean GDS for a known PDK in weeks, not months. ###### What "product, not bespoke" means Fab-ready SoC IPs are versioned artifacts built from registered blocks — new programs compose and extend, rather than restart integration. ##### How We Ship Silicon in Weeks Push on Green Silicon Vyges operates a fully automated silicon delivery pipeline where a change that passes all verification gates can be promoted to a fab-ready artifact with no human handoffs. This yields speed, repeatability, and auditability across every chip we ship. - → Single source of truth (machine-readable SoC intent) - → Deterministic generation of RTL, configs, and integration glue - → Mandatory verification gates (lint, sim, synthesis, P&R where applicable) - → Artifact promotion only on green - → Immutable, signed outputs If it's green, it's shippable. This discipline is enforced by internal generation and CI systems used exclusively to deliver Vyges silicon products. ##### What we've shipped Status legend: `shipped` = public & in use · `submitted` = entered into a public process · `verified` = end-to-end pipeline run on a real artifact · `hardened` = through OpenLane to GDS · `taped out` = sent to fab Artifact Status Evidence VyCatalog™ — open silicon-IP registry shipped 150+ IPs Browse VyCatalog Edge Sensor SoC taped out Sky130 · Chipfoundry Contest 2026 GitHub · contest link pending VySeal™ pipeline verified 2026-04-02 End-to-end run OpenLane macro library hardened 7 macros, incl. SRAM Macro list ##### The Edge Sensor SoC — taped out on Sky130 taped out ###### What it is The Edge Sensor SoC is a fully integrated system-on-chip — taped out on Sky130, and entered in the Chipfoundry Contest. It demonstrates Vyges' ability to deliver fab-ready SoC IP — pre-integrated, verified, and metadata-complete — without the months-long outsourced integration typically required to reach tapeout. The contest entry also includes firmware, a reference PCBA, and a mechanical enclosure — showing the SoC working end-to-end in a complete edge-sensing system, not as a bare die on a tester. - CPU: Ibex (RISC-V) - Peripherals: UART, SPI, FFT accelerator, PLIC - Target PDK: Sky130 - Integration: End-to-end via Vyges registry, generators, and CI - System deliverables: firmware (runs on the SoC), reference PCBA (hosts the chip), and mechanical enclosure (productized form factor) — produced alongside the SoC for the contest entry - Status: Taped out on Sky130 (Chipfoundry Contest 2026 entry) Block diagram Hardened floorplan (user_project_wrapper) Mechanical enclosure (productized form factor) The firmware, PCBA, and mechanical enclosure exist to demonstrate the SoC in a real edge-sensing application — they are proof that the chip works at the system level, not a separate Vyges product line. Note: this submission does not involve VySeal — VySeal is a separate, independently verified artifact (see "What We Ship"). ###### FPGA Hardware Validation FPGA is evidence of correctness, not the product. It exists to prove the SoC integration works before tapeout. As part of pre-silicon validation, the Edge Sensor SoC has been synthesized and validated on FPGA hardware. This FPGA bring-up exercises the same integrated SoC design that was taped out, providing early functional confidence prior to tapeout. - • End-to-end SoC build validated on FPGA hardware - • CPU, peripherals, and interconnect exercised on real hardware (not simulation-only) - • Same RTL that was taped out on Sky130 - • Reference: FPGA Hardware Validation Edge Sensor SoC FPGA bring-up (pre-silicon validation) ###### Tapeout & contest status - • Status: taped out on Sky130 · also submitted to the Chipfoundry Contest - • Repository: github.com/vyges/vyges-edge-sensor-soc - • Contest entry page: link pending publication ##### VySeal™ end-to-end pipeline verified 2026-04-02 VySeal is the IP licensing and delivery infrastructure for commercial silicon. The end-to-end pipeline — sign → package → deliver → synthesize — was verified end-to-end on 2026-04-02 against a real Vyges commercial IP block, producing a synthesizable result downstream of the delivered package. - • Pipeline stages exercised end-to-end: sign → package → deliver → synthesize - • Run against a real Vyges commercial IP block (private; identity withheld pending public-program release) - • Synthesis verified downstream of the delivered package - • Independent of the Edge Sensor SoC submission — separate verified artifact Stage 1 Sign Author signs the IP package → ↓ Stage 2 Package Sealed bundle assembled → ↓ Stage 3 Deliver Recipient verifies and unlocks → ↓ Stage 4 Synthesize Synthesizable result downstream VySeal end-to-end pipeline — verified 2026-04-02 ##### OpenLane macro library hardened Seven hardened GDS macros — the building blocks underneath the Edge Sensor SoC — taken through OpenLane to GDS on Sky130, including SRAM macros. rv_core_ibex_tlul Ibex CPU core, TL-UL bus xbar_main Main TL-UL crossbar fft_ctrl_tlul FFT accelerator (incl. SRAM) spi_host_lite SPI host controller uart UART peripheral rv_plic_lite RISC-V interrupt controller edge_sensor_glue Top-level integration glue All 7 hardened macros placed in the user_project_wrapper, Sky130 GDS files: vyges-edge-sensor-soc/gds/. Vyges builds silicon products; the registry and infrastructure are how we compound speed, reuse, and trust across generations of chips. ##### License fab-ready SoC IP, or commission silicon? Vyges builds and licenses fab-ready SoC IP and commissions silicon for buyers who would otherwise spend millions and months on outsourced integration. Talk to us about silicon Browse VyCatalog ### Technology Source: https://vyges.com/technology/ #### The Infrastructure Behind How We Ship Silicon Vyges uses metadata, automation, and verification internally to deliver fab-ready SoC IP faster. This page explains the architecture — not a product you buy. Why we deliver silicon in weeks, not months ##### We build silicon. AI helps us build it dramatically faster. Design chips — not orchestrate tools. A model reasons about the design; Vyges executes it against real sign-off engines and your own IP — so a tapeout that took months takes weeks. ` AI reasons ─► your AI IDE / vyges mcp ─► Loom executes ─► VyCatalog remembers ─► Silicon (connects AI to tools) (sign-off + fixes) (reusable IP + metadata) (weeks, not months)` ###### Bring any AI model A model can talk about closing timing — it cannot run your extraction, timing, or verification, and it does not know your IP or your PDK. Vyges is the layer that lets any model actually do the work — the same tools, the same metadata, the same silicon flow, whichever model you pick. - • Bring any AI model — general-purpose (Claude, GPT, Grok), open-weight (Qwen, Llama, DeepSeek), or a semiconductor-specific model such as SemiKong. Swap it anytime; the flow doesn't change. - • Runs on your hardware — your RTL never leaves the building. - • Deterministic execution — pull the AI out and the identical flow runs in CI. AI models are replaceable. Your silicon flow isn't. Validated with SemiKong. A locally hosted SemiKong model has driven `vyges mcp` tool calls end-to-end — running a real deterministic sign-off engine to a correct verdict, entirely on local hardware. Every engineer already knows how to use Claude or Cursor. Now those same assistants can drive real silicon implementation tools. See how it works → ##### Reimagining the Hardware Design Lifecycle Silicon design is traditionally phase-gated and manual. Vyges redefines each phase with automation, open tooling, and metadata orchestration — reducing friction from spec to silicon. ###### Planning Define intent, capture specs, and extract constraints with clarity and structure ###### Implementation Develop, verify, and synthesize RTL with integrated AI and automation ###### Execution Achieve timing closure and generate GDSII-ready layouts with minimal iteration ###### Fulfillment Validate silicon, manage packaging, and distribute through trusted catalogs ###### Phases 1 & 2 — Front-End Acceleration Most silicon teams are integrators, not IP authors. Vyges accelerates the front end through two paths — pick from pre-built IPs already in the open registry, or author new IPs and glue modules with the Vyges Metadata Standard enforced inside the IDE. Most programs use both. ###### Path A — Rapid integration via VyCatalog™ For application developers and integrators - • Compose SoCs from 150+ open-source IPs already in the registry - • Each IP is described once by the Vyges Metadata Standard — no spec drift, no transcription errors at integration time - • Machine-readable interfaces, parameters, and registers — searchable by engineers and AI agents - • Time-to-value over time-to-build ###### Path B — Build with VyContext™ For core systems developers writing RTL or glue modules from scratch - • AI IDE extension (VS Code, Cursor) that enforces the Vyges Metadata Standard inside the editor - • Templated directory structure for ASIC, FPGA, and chiplet flows - • Metadata is version-controlled with the RTL — registers, parameters, interfaces stay in sync - • Designed for the engineer authoring the IP that the registry will distribute ###### Phases 3 & 4 — Backend & Fulfilment Vyges supports backend success today through open and commercial PDKs, and operates the silicon fulfilment infrastructure that delivers verified IP to fab. ###### Phase 3: Execution Enablement - • Any-PDK retargeting via the PDK Descriptor Standard — open + commercial, SKY130 / GF180MCU and beyond - • Integration with commercial and open-source EDA tools - • Timing closure automation with constraint reuse - • GDSII output generation and DRC-ready checks ###### Phase 4: Fulfilment Development - • VyCatalog™: open registry of reusable silicon IP - • VySeal™: IP licensing and delivery infrastructure for commercial silicon - • Automated raw die test workflows - • Templated test board and bring-up support - • Silicon validation automation and dashboards - • Yield analysis and quality assurance tooling ##### Mapping Vyges Products to Design Phases A modular system of tools and flows designed to streamline every stage of silicon IP development — from first spec to verified release. ###### Vyges CLI One command-line interface to manage the entire IP lifecycle — from spec to release and compliance. Learn More → ###### VyContext An AI IDE extension that enforces Vyges Metadata Standard conventions inside VS Code and Cursor — onboard faster and ship consistent IP. Learn More → ###### VyBox A portable testbench and PDK flow environment — from RTL to GDSII in a container. Learn More → ###### Post-Silicon Tools for chip bring-up, raw die testing, and dev board workflows — crucial for silicon validation. Learn More → ###### VyCatalog Explore, publish, and reuse IP with full metadata, docs, and version control — in one place. Learn More → ###### VySeal Secure your IP with encryption, signing, and compliance — ready for trusted distribution. Learn More → ###### Vyges Loom Open EDA sign-off suite — characterization, extraction, power, timing+SI, IR/EM, thermal, and LVS, over the geometry kernel. Learn More → ###### VyShuttle From verified IP to silicon — MPW shuttle access and your launchpad to fab. Learn More → ###### Vyges Metadata Specification: The Foundation One metadata layer. Every stage, every tool. The Vyges Metadata Specification is the backbone of lifecycle automation. Engines can be reimplemented; a standard becomes infrastructure. The Vyges Metadata Standard is the layer AI can actually understand — and the one with network effects. ###### Phase 1: Planning Requirements, design intent, and constraints — captured in a structured format ###### Phase 2: Implementation RTL config, test targets, and synthesis settings — standardized for automation ###### Phase 3: Execution Timing, layout guidance, and toolchain compatibility — all metadata-defined ###### Phase 4: Fulfillment IP licensing, packaging, and deployment rules — embedded and validated Explore Metadata Specification → Explore PDK Descriptor Standard → ##### The Problem We Solve Silicon IP development today is slow, fragmented, and error-prone. Disconnected tools, handwritten metadata, and inconsistent standards create friction across teams — delaying time to market and inflating cost. ###### Fragmented Ecosystem Tools and teams operate in silos. There's no standard way to create, package, or integrate IP across vendors or flows. - • Siloed tools, formats, and ecosystems - • Vendor lock-in and lack of reusability - • Disconnected metadata and IP discovery - • RRedundant work across teams ###### Manual Overhead Handwritten metadata. Manual verification. Glue scripts everywhere. Scaling across teams becomes painful. - • Manual spec creation and constraint handling - • No automation for validation or testbench generation - • Repetitive glue logic and file conversion - • Inefficient collaboration in multi-IP environments ###### Quality Inconsistency Without a clear compliance baseline, IP quality is unpredictable — leading to late-stage failures and costly debug cycles. - • No uniform QA or compliance layer - • Inconsistent documentation and coverage - • Debug and bring-up delays - • Hidden errors found post-silicon ##### Our Revolutionary Solution One platform. Every phase. Vyges automates IP creation, validation, and integration — making silicon development faster, scalable, and verifiable by design. ###### A Unified, Metadata-Driven Architecture Vyges unifies the entire silicon IP lifecycle — from requirements to GDSII — into a single schema-driven workflow. No more handoffs, no more glue scripts. With intelligent automation at every step, teams can move faster, collaborate better, and trust the quality of what they build. ###### Key Differentiators - • Unified metadata spec covering the entire lifecycle - • Auto-generated testbenches, quality reports, and checks - • AI-assisted RTL, constraint, and doc generation - • Works with both open-source and commercial EDA flows ###### Core Components of Vyges ###### Metadata Engine JSON-based schema for describing, validating, and orchestrating IP components ###### CLI Framework Developer-friendly tools for validation, automation, and continuous integration ###### AI Integration Generative models for RTL, testbenches, constraints, and docs — boosting productivity ###### Ecosystem Platform Tools for secure IP distribution, signing, and metadata-based cataloging ##### The Vyges Architecture Vyges is built on a three-layer architecture that spans the entire silicon IP lifecycle—combining intelligent creation, standardized validation, and seamless deployment. Designed for scale. Engineered for trust. ###### Three-Layer Model: Intelligent Creation to Verified Deployment ###### Intelligent IP Creation AI-powered templates and assisted development accelerate RTL, constraints, and documentation — right from the start. ###### Standardized Metadata & Discovery Everything is metadata-defined — enabling schema-based validation, compatibility scoring, and catalog search. ###### Seamless Integration & Deployment CI pipelines, toolchain orchestration, and platform-aware packaging for ASIC, FPGA, and chiplets. 1 ###### AI-Driven IP Development Smart templates and generative tools speed up development while ensuring structure, metadata completeness, and quality from the start. - • Generative RTL, constraint, and doc automation - • Metadata auto-filled from template or CLI - • Reusable, customizable IP templates - • Built-in QA, linting, and folder hygiene 2 ###### Metadata-Driven Validation & Search Structured metadata makes every IP block discoverable, verifiable, and interoperable—reducing risk during integration. - • Schema validation and compliance scoring - • Coverage tracking and test readiness checks - • Searchable IP catalogs (API & UI) - • Compatibility and dependency analysis 3 ###### Orchestrated Deployment & Toolchain Integration Vyges connects to your toolchain and automates integration—from synthesis to packaging—with traceable, production-ready output. - • CI-ready automation and tool scripts - • GitHub Pages reports and dashboards - • Flow-aware packaging (ASIC, FPGA, chiplet) - • PDK and EDA tool config auto-generation ##### Why This Model Works Vyges compounds value at every phase — accelerating delivery today, and future-proofing your silicon design flow for scale, reuse, and collaboration. ###### For Current Customers ✓ ###### 75% Faster Frontend Execution Accelerated planning, templating, and AI-assisted RTL generation ✓ ###### 50% Lower Backend Costs Toolchain flexibility across open and commercial flows ✓ ###### QA by Design Automated test coverage, traceability, and continuous validation ✓ ###### Future-Ready Architecture Modular, schema-based, and built for evolving teams ###### For Green Field Customers ⚡ ###### Best Practices Out of the Box Start with proven templates and structure from day one 🔗 ###### Connect to Reusable IP Browse, integrate, and extend trusted, high-quality blocks 📈 ###### Grows With You No refactoring as designs or teams scale 🎯 ###### Go to Market Faster Accelerate silicon cycles by weeks or even months ##### The More You Build, The Better It Gets Vyges thrives on momentum. Every new IP, user, or integration adds value—boosting automation, discoverability, and intelligence across the ecosystem. ###### A Living, Expanding IP Library Every IP published enriches the ecosystem—accelerating reuse, improving discovery, and enabling smarter integration across teams. - • Rapidly growing library of validated IP blocks - • Searchable by interface, function, or compatibility - • Reuse across projects with minimal rework - • Faster delivery using prebuilt components ###### Fewer Scripts. More Focus. With each new tool integration, manual steps vanish—empowering engineers to spend more time designing and less time wiring flows together. - • Native support for open and commercial EDA tools - • Auto-configured flows, no scripting required - • Compatibility checks across tool versions - • Out-of-the-box support for CI/CD and packaging ###### AI That Learns From the Community As more projects and teams use Vyges, its AI becomes sharper—delivering higher-quality code, tighter tests, and smarter automation. - • AI adapts with every IP created - • Better suggestions for RTL, constraints, and docs - • Predictive quality metrics and coverage analysis - • Optimized workflows tailored to your patterns ##### Build Silicon Smarter. Together. From lean startups to enterprise design teams, Vyges empowers faster silicon development, better quality, and scalable collaboration—at every stage of the journey. Try Vyges CLI Get in Touch ### Metadata specification Source: https://vyges.com/technology/metadata-spec/ #### Vyges Metadata Specification A machine-readable schema for describing reusable silicon IP — the foundation of the Vyges Metadata Standard and the open registry built on it. View Schema GitHub Repository ##### What is the Vyges Metadata Specification? This page documents the Vyges Metadata Specification — the schema document — and the Vyges Metadata Standard that it implements. The Vyges Metadata Specification is a structured, extensible JSON schema for describing hardware IP blocks. It enables automated validation, reuse, and integration across toolchains. The Standard the Specification implements is what makes silicon IP composable, governed, and AI-agent-consumable across the Vyges open registry, the private catalogs we operate for buyers, and the silicon products we ship. Explore Schema Read Documentation ###### Key Features - Machine-readable JSON schema - Detailed and structured descriptions for RTL, interfaces, and constraints - Built-in fields for license type, usage policies, and export compliance - Explicit port, protocol, and signal-level definitions - Capture timing, area, power, and throughput goals - Metadata extensions for chiplet packaging and die-to-die connectivity ##### What the Standard replaces — the Excel-as-spec problem The Vyges Metadata Standard turns the spreadsheet into a code artifact. Registers, parameters, and interfaces are version-controlled with the RTL — no second source of truth, no spec drift, no transcription errors at integration time. "Machine-readable" is an abstract claim until you name what it replaces. Today, the canonical truth for an IP's registers, parameters, interfaces, integration constraints, and target PDKs lives in Excel spreadsheets maintained by engineering teams alongside the code — supplemented by Word docs, wiki pages, PDF datasheets, and tribal knowledge. This is the actual workflow inside most IP teams, and it is broken in three predictable ways: - Drift between spec and code. A register added in RTL but missed in the spreadsheet (or vice versa) is a routine occurrence; reconciliation is manual, sporadic, and never complete. - Copy errors during integration. When the IP is reused in another design, register addresses, bit fields, and parameter constraints are transcribed by hand into the consumer's RTL — and transcription introduces errors that don't surface until simulation or, worse, silicon. - Information loss across handoffs. When an engineer leaves, when a project is paused, or when an IP is licensed to a third party, the spec docs and the code drift apart. Years later, no one is sure which version of the spreadsheet matches the tagged RTL release. The Vyges Metadata Standard eliminates this entirely. The metadata lives next to the code, in the same repository, under the same version control, in the same release tag. There is no separate spreadsheet to update, no doc to keep in sync, no wiki page to maintain. Updates to registers, parameters, or interfaces flow through the same commit as the RTL change — there is no second source of truth to drift from. No more Excel reconciliation. No more copy errors. No more "is the spec current?" ##### Why a Schema-First Approach Works A standardized metadata layer creates alignment across IP providers, integrators, and EDA tools—enabling repeatable automation, easier collaboration, and faster delivery. ###### Discoverability Rapidly find and filter IP blocks using consistent metadata across your organization or ecosystem. ###### Composability Match and integrate IPs faster with explicit interface, constraint, and compatibility metadata. ###### Automation Power toolchains with structured inputs for validation, linting, integration, and compliance checking. ##### One engine, two configurations The same Standard. Two operational modes — open and private. The public Vyges open registry and the private catalogs we operate for enterprise buyers are not parallel rewrites of one another. They are two configurations of one system — same registry engine, same metadata model, same version lifecycle, same dependency graph, same governance core. Access control, identity, and audit features differ to fit confidentiality and compliance constraints, but the Standard underneath is identical. Two consequences fall out of this. The public registry continuously scale-tests the enterprise deployment — whatever the open catalog handles in load, integrity, and correctness, enterprise inherits without a separate hardening cycle. And fixes flow in both directions: a bug fixed on the public surface is fixed in private; a hardening done for an enterprise buyer reinforces the open registry. There is no fork to drift. ##### Why machine-readable matters in the AI era Structure converts an unbounded grep into a bounded read. A Standard that LLMs and search agents can query directly is dramatically cheaper than greppable code. Every question answered from metadata instead of raw RTL is a token bill avoided and a context window kept free for reasoning, not parsing. Across a 10,000-IP enterprise estate — including the archived repos nobody wants to index — that is the difference between "we should look it up" and "we already know." ##### Open standard, protected ecosystem Published openly under the Apache License, Version 2.0. The legal posture is summarised below; the canonical statement lives in the NOTICE file in the schema repository. ###### Patent posture TrustStix Inc., operating under the name Vyges, has filed provisional patent applications covering aspects of the Vyges ecosystem architecture — specific methods for metadata-driven IP discovery, workflow orchestration, and end-to-end silicon delivery. Nothing in the NOTICE limits or conditions the rights granted under the Apache License, Version 2.0. The patent filing does NOT affect: - Reading, implementing, or extending the Vyges Metadata Specification - Internal or commercial use of software implementing the Specification - Creation of independent tools, services, or IP using the Specification - Use of Vyges IP templates or Vyges-generated IP blocks distributed under the Apache License, Version 2.0 Vyges retains all rights in its patented methods and systems, to the extent not licensed under the Apache License, Version 2.0, as well as in: - Its hosted services, registries, and commercial offerings - Its trademarks, service marks, and certification programs ###### Trademarks and conformance "Vyges", "VyCatalog", and related names are trademarks or service marks of TrustStix Inc. Claims of compatibility, conformance, or certification with the Vyges Metadata Specification — including descriptors such as "Vyges-compatible", "Vyges-conformant", "Vyges-certified", or "certified for VyCatalog interoperability" — require authorization from Vyges. Vyges operates, or may operate, a Vyges Conformance Program under which validation tools, test suites, and certification rights are made available pursuant to a separate written agreement. Reading the Specification, implementing it internally, or building tools that consume Vyges-format metadata does not require participation in the Conformance Program. Commercial offerings that publicly claim Vyges conformance or certification do. Nothing in this notice restricts truthful, nominative references to the Vyges Metadata Specification where no endorsement, certification, or affiliation is implied. Inquiries — patent licensing, commercial agreements, and conformance program: patents@vyges.com. Full canonical text: NOTICE on GitHub. ##### Get Started Begin integrating the Vyges Metadata Standard into your IP creation, validation, and publishing flow. ###### Read the Spec Explore the full metadata schema and understand its structure, fields, and use cases. View Schema → ###### Create Metadata Use Vyges CLI to generate and validate metadata for your IP blocks—fast and error-free. Use Vyges CLI → ###### Join the Community Help evolve the standard. Propose changes, submit feedback, or contribute new extensions. Contribute → ### PDK specification Source: https://vyges.com/technology/pdk-spec/ #### Vyges PDK Descriptor Standard A manifest for every PDK — one uniform descriptor that presents any process design kit to the tools that consume it — any node, from advanced 2 nm to mature 130/180 nm and beyond. TL;DR: a single JSON manifest that lets tools consume any PDK the same way — without reworking flows. View Schema Download PDKs ##### Why we built this At Vyges, we practice AI-native silicon engineering. With VyCatalog, verified silicon IPs drop straight into the workflow, and every artifact a quality chip needs (RTL, firmware, tests, constraints, hardening) is generated from metadata, not hand-assembled. In our internal work this collapses composing an SoC, verifying it, and bringing it up on both FPGA and ASIC from many months to days or weeks. When iteration is that fast, a new question opens up: What if you built the same design against a different PDK? A smaller die. A tighter power budget. A cheaper or more available node. A more mature process for better yield. Sweeping several PDKs for die size, cost, node availability, or yield was almost impossible in the past — too slow to be worth it — so designs were locked to one process early and rarely revisited. At software speed it becomes just another axis to explore. When the flow is software, retargeting should be a flag — not a project. But every PDK is laid out differently: heterogeneous collateral, paths, corners, and cell libraries. Swapping by hand is slow and error-prone — the opposite of "like software." So we built the missing piece: one uniform way to present any PDK to the flow. One descriptor per PDK; swap with `--pdk sky130` or `--pdk gf180mcu`; the generator and the sign-off engines do the rest. And the PDK Descriptor Standard was born. ##### What is the PDK Descriptor Standard? A PDK descriptor (`*.vyges-pdk.json`) maps a PDK's heterogeneous on-disk layout onto a uniform set of collateral keys. A flow resolves `--pdk ` + a corner (+ a cell library) to concrete file paths — regardless of node, foundry, layout, or hosting. It is a presentation contract on top of existing PDK hosting — Ciel (the open-PDK distribution manager used for sky130 / gf180), mirrors, and private object stores — it does not host, index, or re-implement that infrastructure. The descriptor is data; engines stay path-based; the `pdk-store` resolver that reads it is downstream. Explore Schema Download PDKs ###### Key Features - Node-agnostic by design — maps collateral categories, not contents; stable across nodes — 2 nm to 130/180 nm and beyond - Covers three sources uniformly — Ciel-managed open PDKs, non-Ciel on-disk PDKs, and access-controlled NDA / customer PDKs - Resolves corners + cell libraries to concrete file paths for general OSS tools and the Vyges Loom engines alike - Live in 6 public PDK mirrors — sky130, gf180mcu, ihp-sg13g2, asap7, nangate45, icsprout55 - A presentation contract, not a registry — it sits on existing hosting, doesn't replace it ##### Drop it into your flow One descriptor in — every tool resolves the PDK the same way. *.vyges-pdk.json ──► pdk-store (resolve) ──► Vyges Loom: char · extract · power · sta-si · em-ir · thermal · lvs Pull & build Grab a built PDK from pdk-releases — ciel-compatible, per-library tarballs — and start. No spelunking through directory layouts. One resolve, every tool `pdk-store` turns `--pdk ` + a corner into real collateral paths. All six Loom sign-off engines — and the optimizers — read the same map. Zero per-tool wiring. Retarget with a flag It maps collateral categories, not contents — so the same keys hold from 2 nm to 180 nm. Swapping PDKs is a flag, not a project. A presentation layer over your existing PDK hosting — it never moves, renames, or redefines a single file. OpenLane and LibreLane keep their native resolution; everything else gets one uniform map. One map per PDK. Schema-checked, CI-tested, versioned — the same shape for every node. ##### For PDK providers & foundries A PDK descriptor is the "nutrition label" / `package.json` for a PDK — a small, vendor-neutral manifest a foundry ships alongside its PDK so any tool (open or commercial) can consume the PDK uniformly without bespoke per-tool wiring. Ships with the PDK — a small manifest beside your existing collateral No change to your directory layout — it describes what's already there Can live under NDA — private descriptors stay in your store; nothing internal is exposed Tooling interoperability — open or commercial tools consume the PDK the same way, without exposing internals Any tool can consume the descriptor directly — the Vyges Loom engines are simply the first adopters. We're publishing this openly to enable discussion, adoption, and iteration — not to gate or centralize control. ###### Canonical schema JSON Schema 2020-12 · 21 top-level fields · 6 required `https://vyges.com/schema/v1/vyges-pdk.schema.json` Open the interactive schema viewer ### Design chips, not orchestrate tools Source: https://vyges.com/technology/tool-sprawl/ #### Design chips — not orchestrate tools EDA has become a tool-management problem. Vyges gives your team one interface — driven by any AI model — so engineers work on the chip, not on a dozen tool dialects. AI is collapsing the value of tool expertise. Here's what that changes. ##### A silicon team is staffed around tools Every sign-off tool speaks its own dialect — its runsets, its quirks, its decades of accumulated flags. So teams are hired as a PrimeTime person, a Calibre person, an Innovus person — specialists in a tool, not in the chip. The expertise that gets bought and priced is "can you drive this tool," not "can you close this chip." PrimeTime Innovus ICC2 Calibre StarRC Voltus Tempus Pegasus OpenROAD OpenLane Yosys Magic KLayout …and a dozen more That is expensive, scarce, and brittle — and a barrier to everyone outside the incumbents. ##### The hiring tell Today, you hire a PrimeTime engineer a Calibre engineer an Innovus engineer Tomorrow, you hire a Chip Engineer The AI drives the tools. ##### AI can finally orchestrate the tools A model reasons about the design; Vyges executes it — driving the sign-off engines through one interface (`vyges mcp`), locally, whichever model you bring. You express intent — "close timing," "fix these DRC violations" — not which of fourteen tools, and which flags. - → One interface across Loom's open engines and your existing open-source or commercial tools - → Any AI model — Claude, an open-weight model, or your own — driving it locally; your RTL never leaves the building - → Deterministic underneath: pull the AI out and the exact same flow runs in CI The tools still run underneath — you no longer have to be their operator. Your engineers are freed to work on the chip, not the toolbox. How the execution layer works → See the Loom engines → ##### Staff around the chip, not the tool AI‑native silicon engineering — bring any model, run it locally, and ship silicon in weeks. Talk to us Why we deliver faster ### AI that actually fixes designs Source: https://vyges.com/technology/ai-fixes/ #### AI that actually fixes designs Most AI can talk about a failing timing report. Vyges lets a model fix it — driving real optimizers and sign-off engines until the design is green. The AI proposes; deterministic engines do the work and score every move. ##### The fix loop A model reads the verdict, proposes a change, a deterministic engine applies it, and the result is re-scored — repeat until it's green. `loom.feedback` gives the agent its eyes: one call returns a rendered layout, categorized verdicts, and a score — so an agent can debug a design, not just pass/fail it. ` read the verdict → propose a fix → engine applies it → re-score → green? ▲ │ └──────────────────────────── not yet ───────────────────────────────┘` Every move is scored by the same sta-si timer that signs the design off — so a "fix" that breaks something else can't slip through. ##### What it fixes — with real engines, not hand-waving Each fix is a real Engineering Change Order (ECO) — a targeted, incremental netlist edit — from a Loom optimizer, scored against the same sign-off. ###### Failing setup → resize Pick 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 → vt-swap Trade threshold voltage iso-footprint: high-Vt to cut leakage where there's slack, low-Vt to close setup. ###### Bad transition → buffer-insert Split a heavily-loaded net so the driver's transition drops back under the limit, timing still met. ###### Post-route hold → hold-fix Insert series delay on hold-violating capture pins, scored against real routed parasitics. ###### DRC violations → repair loop Categorized DRC verdicts + a rendered overlay via `loom.feedback` — the agent sees where and iterates, plus metal-fill to hit density. ###### LVS mismatch → named divergence A name-independent graph match returns MATCH/MISMATCH with the divergence named — the agent knows exactly what to reconcile. ##### Deterministic underneath - → The AI is a driver — never inside the engines. The fixes are real, deterministic ECOs. - → Every candidate fix is scored by the same sign-off that gates the tape-out — no regressions sneak through. - → Pull the AI out and the exact same flow runs headless in CI, reproducibly. - → Runs on your own hardware, driven by any AI model through `vyges mcp` — your design never leaves the building. This is where AI has immediate, demonstrable value in silicon: not writing prose about a report, but closing the loop on a real one. See all the Loom engines → ##### Point your AI at a real failing design Bring any model, run it locally, and let it fix — not just describe — your timing, power, and DRC. Explore Loom Talk to us ### A Floorplan Without the Village Source: https://vyges.com/about/blog/posts/2026-08-31-a-floorplan-without-the-village/ #### A Floorplan Without the Village Six steps. Four binaries. No container, no Tcl, no orchestrator. And on the one block we can check against a taped-out design, the rows and tracks match exactly. August 31, 2026 • By Shivaram Mysore To get a floorplan out of an open flow today, you install the flow. All of it. The orchestrator, the Python environment it wants, the tool binaries it drives, the container that holds the arrangement together. Then you write a configuration, run the flow, and wait — and what you wanted was to know whether your die was big enough. That is not anybody's fault. It is what happens when the only way to reach a step is through the machinery built to sequence every step. But it sets a floor on how cheaply you can ask a question, and the floor is high enough that people stop asking. We have been building the floorplan stage as individual engines. They are now far enough along to run as a chain on their own: `` The usual arrangement netlist ──► [ orchestrator + Python + Tcl + container + tools ] ──► floorplan This netlist ──► import ─► ifp ─► make-tracks ─► tap ─► global-connect ─► pdn ──► floorplan └───────────────── four static binaries ──────────────────┘ `` Six logical steps, implemented by four static binaries. Two of them carry more than one stage — `ifp` builds the rows and the tracks, `pdn` connects the supply nets and then builds the grid — but every stage stays independently invocable, which is the property that matters. Nothing here starts a container, sources a Tcl script, or needs anything from PyPI. ##### What it actually does Each step is an ordinary command that reads a design database and writes one back: - `import` builds a database from LEF and a gate-level Verilog netlist. - `ifp` turns the die rectangle into a floorplan — core area snapped to the site grid, and the rows every later stage places into. - `make-tracks` lays the routing tracks from the technology's own pitches and offsets. - `tap` cuts the rows around macros and places the well taps and endcaps. - `global-connect` creates the supply nets and connects every cell's power pins to them. - `pdn` builds the grid: follow-pin rails, straps, and the vias that stitch the layers together. The final output is a DEF. What is not in that list matters as much as what is: placement, clock-tree synthesis and routing are not here. This is the floorplan, and calling it anything more would be a claim we cannot support. ##### Checked against a real tapeout, not against itself A tool agreeing with itself proves nothing, so we ran it on a design that has been fabricated. The Vyges edge-sensor SoC is a taped-out sky130 chip, and its repository ships every block's gate-level netlist, its signed-off configuration, and — for one block — the DEF that went to fabrication. Every number the flow uses is read from that configuration: die area, site, PDN layers, widths, pitches, offsets. The script chooses nothing. All seven blocks complete the floorplan stage cleanly: Block Design cells Rows Components out Power shapes Vias `edge_sensor_glue` 301 212 5,540 229 2,588 `rv_core_ibex_tlul` 943 506 29,133 543 13,851 `xbar_main` 2,314 396 19,822 425 8,435 `rv_plic_lite` 3,281 139 5,674 150 1,063 `spi_host_lite` 7,868 175 11,492 189 1,869 `uart` 13,363 249 20,512 268 3,416 `fft_ctrl_tlul` 14,207 543 42,270 581 14,042 Design cells are what the netlist contains. Components out is what the DEF contains afterwards — the design plus the well taps and endcaps this flow inserts, which is most of the difference. `rv_plic_lite` goes from 3,281 to 5,674 because `tap` placed 2,393 physical cells into it. For `fft_ctrl_tlul`, the largest of them, the taped-out DEF is in the repository — so the flow finishes by comparing its own floorplan against the physical implementation that went to fabrication. All 543 rows and all 12 DEF track statements are identical. Rows and track statements are the right things to compare that way, and they are the only ones. They are settled at floorplan and never move afterwards, so they survive intact into a fully routed DEF. Components and power shapes do not: placement, CTS and routing all change them. Claiming a match on those would be measuring the wrong thing. The comparison is a real gate, not a decoration — it exits non-zero on a mismatch. It earned that during development, when a coordinate formatter rendered `1294.48` as `1294` and moved the floorplan half a micron. Nothing else in the flow noticed. The check failed immediately. ##### Or start from nothing Matching a tapeout proves the engine agrees with a known-good answer. It is not, though, what you would use this for. Most of the time the floorplan does not exist yet — you have a netlist and a rough idea of how big the block wants to be, and the question is what happens if it were smaller. Give it a netlist and a die and it builds one: ``./flows/floorplan.sh --netlist build/my_block.v --die-area '0 0 600 600' `` That is the whole input. The core comes from the die inset by the margins, the tracks come from the technology's own pitches, and the rest follows. Here is the same 13,363-cell block at four die sizes, nothing changed between runs but the rectangle: Die Rows Effective utilization Wall clock 500 × 500 175 0.583 10.8 s 600 × 600 212 0.399 12.0 s 700 × 700 249 0.291 12.8 s 900 × 900 322 0.174 16.5 s `` 500×500 600×600 700×700 900×900 │ │ │ │ 0.583 0.399 0.291 0.174 effective utilization └───────────┴───────────┴───────────┘ 52 s of compute, total `` Four floorplans in under a minute of total compute. That is a different activity from running a flow: you are not committing to a configuration, you are looking at four of them. Ask for one that cannot work and it says so with a number rather than an opinion. At 300 × 300 the same block reports an effective utilization of 1.692 — the cells require more area than the available core. It does not refuse, and it does not quietly grow the die. It builds what you asked for and hands you the figure that tells you it will not place. The same standalone approach makes power-grid exploration cheap too. Same die, three strap pitches: Strap pitch Power shapes Vias 40 µm 270 9,673 80 µm 242 4,899 153.6 µm 229 2,588 A tighter grid is more robust and costs routing resource, and here the trade is a number you can see before anything downstream depends on it. ##### Seconds, not stages `rv_plic_lite` takes 1.6 seconds. `fft_ctrl_tlul`, at 14,207 cells, takes 36 seconds. Every timing here is single-threaded on one core of a Xeon E5-2699 v4 at 2.20 GHz running Ubuntu 24.04 — a 2016 server part, not a fast modern laptop. Those numbers are what makes the sweeps above ordinary rather than an exercise. There is no batch to submit and no run directory to go back and read: you change a margin, rerun, and look. Install is one command. The whole suite — 28 engines, sign-off and construction together — is a 23 MB download. The four this flow needs come to 7.7 MB. There is nothing else to stand up. ##### Run it yourself The scripts are public, in the Vyges Loom testbench under `flows/`. There are two, and the split is deliberate. `floorplan.sh` is the tool. Point it at your own netlist: ``vyges install physical && vyges install loom export PATH="$HOME/.vyges/bin:$PATH" ./flows/floorplan.sh --netlist build/my_block.v --die-area '0 0 700 700' `` If you do not have the CLI yet, installing it is the one step before this. The PDK is resolved through `vyges pdk-store`, so the script contains no vendor-specific directory layout. `--pdk` selects any registered PDK and `--library` selects any library in it, including a library you cannot redistribute. `edge-sensor-demo.sh` is the worked example. It reads a taped-out block's configuration and calls the same script: ``git clone --depth 1 https://github.com/vyges/vyges-edge-sensor-soc ./flows/edge-sensor-demo.sh --repo vyges-edge-sensor-soc --design fft_ctrl_tlul `` The demo runs the developer's code path rather than a parallel copy of it, which is why the formatter bug above showed up somewhere it could be caught. The design repository is only ever read — it is a fabricated design, and nothing writes into it. ##### What this is not It is not a place-and-route flow. Placement, CTS and routing remain the flow's job. It is not a claim that the flow is unnecessary. An orchestrator sequences steps, manages state, and handles the parts of a tapeout that are genuinely about coordination. What has changed is that reaching one stage no longer requires all of it. It is not a claim that the whole floorplan matches silicon. What is compared are the rows and the track statements — the parts of a floorplan that never move again once set. That is a narrower claim than "matches the tapeout", and it is the one the evidence supports. ##### Why we are showing it this way Everything we have published about these engines until now has gone through `vyges mcp` — an AI agent choosing tools from their descriptions and driving them. That remains the more interesting demonstration. This one is a shell script on purpose. A flow you can read top to bottom, run, and diff against a real tapeout is a different kind of evidence from a model doing it for you: it is checkable by anyone, in the form engineers already trust. The agent story is better when the thing underneath it is boring enough to verify by hand. Try the floorplan flow: the scripts · install the CLI, then `vyges install physical` · the Loom engines ### Context, Capability, Correctness: Three Bets on Trusting an AI Agent Source: https://vyges.com/about/blog/posts/2026-08-12-context-capability-correctness/ #### Context, Capability, Correctness: Three Bets on Trusting an AI Agent Two big agent platforms launched this month. Each addresses a different reason an agent cannot be trusted to act alone. But neither addresses the question that matters when the output is silicon: is the result actually correct? August 12, 2026 • By Shivaram Mysore Within a few weeks of each other, Cloudflare and Spotify each shipped a platform for putting AI agents to work inside a company. Both are serious pieces of engineering from teams who have thought hard about the problem. What follows is my reading of the two, not a summary of claims either company makes. Neither presents its platform as a complete answer to whether an agent can be trusted, and I am not suggesting either does. What is interesting is that when you line them up, they turn out to have picked different halves of the problem — and that the half neither picked is the one my industry cannot ignore. Both are also days old. Announcements describe intent; the rough edges show up later, and platforms of this reach accumulate a lot of surface to get wrong. Read the quotes below as design intent rather than field results — mine included. Every agent platform is a bet on a single question: why can't we just let the thing act? There are three defensible answers. ##### Bet one: it doesn't know enough Spotify's answer is context. Their framing of the failure is the sharpest sentence I have read on this: AI agents made fast, confident decisions that were technically correct and operationally wrong. Technically correct and operationally wrong. Every engineer recognises that. The change compiles, the tests pass, and it is still the wrong thing to have done — because it ignored a decision the team made two years ago, or a service ownership boundary, or a constraint that lives in somebody's head and one Slack thread. Their remedy is retrieval: capture what the organisation knows, keep it current, and feed it back so the agent understands your services, your dependencies, your architecture. The bet is that a well-informed agent makes good decisions. ##### Bet two: it can reach too much Cloudflare's answer is capability. Their platform starts every agent with access to nothing and makes it ask: Inside, every agent and app starts with access to nothing. An agent can ask for access to a specific resource, which you can grant or deny. When access is granted, the agent gets a typed object rather than a credential — the secret stays isolated from the agent and from any code it writes. Between the agent and each real service sits what they call a Gatekeeper, which can narrow permission to one repository, allow reading issues but not source, mask fields, apply rate limits. Every resource an agent looks at is recorded, and that record follows the work. Look at that list again and you will recognise it. Deny by default. An access-control list per resource. A policy enforcement point in front of every service. An audit log of everything touched. This is a firewall. It is least privilege and perimeter control, pointed at a new kind of client. That is not a criticism — it is the reason to take it seriously. Least privilege has forty years of operational history behind it, and it is one of the few security ideas that has survived contact with reality more or less intact. Cloudflare, of all companies, knows how to build this, and reaching for a proven model rather than inventing an agent-specific one is the correct instinct. If you must be wrong about something, be wrong about the thing that has been debugged since the 1980s. They are also refreshingly unromantic about where models belong: Many are a known sequence of steps with one or two places where judgment is useful. A workspace can turn those jobs into mostly deterministic workflows, using code for the predictable steps and a model only where it adds value. That is exactly right, and it is the same conclusion we reached from the other end of the industry. But notice what a firewall has never claimed to do. It tells you a packet was permitted. It has never told you the packet was correct. Nobody expects that of it, and no amount of tightening the rules gets you there — a perfectly configured firewall will pass a malformed request all day long, because that was never its job. ##### Bet three: it might simply be wrong Here is the sentence this whole piece turns on. A perfectly informed agent with perfectly scoped permissions can still produce a design that misses timing. Read it slowly, because both platforms address the first two layers directly, and the sentence still holds. The agent knew the systems — every service, every ownership boundary, every architectural decision. It touched only what it was permitted to touch, through a typed capability, with the whole interaction logged. Context: solved. Capability: solved. And the result is still wrong. Nothing in either design notices, because noticing was never what either was built to do. That is not an oversight. Read both announcements closely and you find careful engineering around what an agent knows and what it may touch, and silence on whether what it made is right. Cloudflare logs everything an agent observed — but an audit trail tells you what happened, not whether the result is good. And in their domains, they cannot do much better. Ask "is this internal workflow correct?" or "is this service refactor right?" and there is no program you can run that returns a trustworthy yes or no. The best available answers are the tests somebody wrote and the judgment of somebody who knows. Given that, context and capability really are the only two levers available, and both companies pulled theirs well. ##### Why silicon is different Chip design is one of the few engineering domains where correctness is not a matter of opinion. Does this layout violate the process rules? Does the netlist match the schematic? Does the design meet timing once you account for parasitics and crosstalk? These are not questions you settle in code review. They are computations, and they return a verdict. The domain gives you deterministic checks for important classes of correctness. That changes what is possible. If a machine can decide whether the answer is right, then an agent can be allowed to propose freely, because something other than the agent gets the final say. The model plans; deterministic tools decide. This is the thread we have been pulling on with Vyges™ Loom — open sign-off engines that check geometry, connectivity, parasitics and timing, and that describe their own interfaces so a model can discover and drive them without bespoke integration code. The engines are deterministic. Run them twice on the same input and you get the same verdict, whichever model asked. ##### Where we actually are I want to be careful here, because it would be easy to write the triumphant version of this post and it would not be true. This is early. The engines run, the verdicts are real, and we have correlated them against reference tools and published what we found, including where we came up short. That makes it a credible proof of concept. It does not make it a practice anyone depends on yet. The harder part is not engineering. It is that adding a second, independent opinion to a sign-off flow is a change in how a team works, and changes like that are earned on somebody's real design, not in a blog post. No silicon team has yet built this into how they operate. Until one does, the honest description is "promising and unproven." There is also a question we have not answered: whether an independent verdict is even the thing teams most want. It might be. It might turn out that what actually hurts is time to sign-off, or the tax of maintaining a dozen tool dialects, and that verification is the interesting-but-secondary part. We have a hypothesis. We do not yet have enough conversations to know. ##### Three layers, not three competitors The useful conclusion is that these are not rival products. They stack. The question Failure it prevents Context Does the agent know enough? Confidently doing the wrong thing Capability What may it reach? Touching what it should not Correctness Is the result right? Shipping a broken result Which returns us to the sentence above. Context and capability both fail open on correctness: they will let a wrong answer through, politely, with a complete audit trail and every permission properly checked. For software, that is survivable; you find out in staging and roll back. For silicon, the feedback arrives as a mask set and a wafer run. That asymmetry is why we think the third layer deserves more attention than it is getting, and why we have spent the year building it in the open rather than as a product feature. ##### We would rather be corrected than agreed with If you build chips and this framing is wrong — if the verdict is not what would help you, or the real pain is somewhere else entirely — that is the most useful thing you could tell us. Three ways to help us find out, in increasing order of how much of your time it costs. Run the engines. Install the suite and point a sign-off engine at something of yours. They are open source and need no account. Installing fetches the binaries from GitHub, as you would expect; after that, running an engine makes no network calls at all — we checked with `strace`, not just by reading our own code. Your design does not leave your machine. If the verdict disagrees with the tool you trust, we want to know that more than we want a clean result. ``# macOS, or Linux with Homebrew brew install vyges/tap/vyges # anywhere else curl --proto '=https' --tlsv1.2 -LsSf \ https://github.com/vyges-tools/cli/releases/latest/download/vyges-installer.sh | sh # then pull the sign-off engines and look at one vyges install loom vyges loom drc --help `` Tell us how you would want to drive them. Every engine describes its own interface, so a model can discover and run them over MCP without integration code. The MCP server is local too — it speaks stdio and runs beside the tools rather than as a service we host, and it makes no network calls of its own. Which model you point at it is your decision, and that decision, not our tooling, is where your data boundary actually sits. That whole design is a bet about how engineers will want to work, and it is a bet made mostly from our own bench. If you have a view on how sign-off should sit next to an LLM in your flow — or a reason the idea is wrong — we would rather hear it now than after we have built more on the assumption. Talk to us about your situation. If you have a block, a flow, or a sign-off problem you are willing to describe, we will tell you honestly whether this is any use to you yet. Sometimes the answer will be no, and that is a useful conversation too. See Vyges Loom · Read the docs · Start a conversation ### Vyges: First Year Anniversary Source: https://vyges.com/about/blog/posts/2026-08-11-vyges-first-year-anniversary/ #### Vyges: First Year Anniversary One year ago today, we launched with a claim: silicon should be built like software. A year on, the catalog is open, the sign-off engines are open, and a chip has gone from specification to tapeout using the foundation we set out to build. August 11, 2026 • By Shivaram Mysore One year ago today, Vyges™ launched with a sentence that sounded simple and turned out to be a lot of work: Build silicon like software. Software solved reuse decades ago. You find a package, read what it needs, pull it in, and let CI tell you whether it still works. Hardware never got that. Silicon IP moved as tarballs and PDFs, and "does this block actually fit my design?" was a question you answered by reading a datasheet and hoping. I have spent two decades building products — more than thirty of them, across five startups — and that contrast never stopped bothering me. The tooling that made software reuse routine was not magic. It was metadata, automation, and a culture of checking. None of that is unavailable to hardware. It simply had not been built. We spent the year building the pieces that could make the software answer possible for silicon. ##### What we built An open IP catalog. More than 160 open-source silicon blocks, each described using a machine-readable metadata standard that captures what the block actually is — its interfaces, files, dependencies, bus information and PDK targets — rather than what a document claims. A CLI resolves and stages them the way a package manager would. Open sign-off. Reuse is only useful if you can check what you pulled. So we built Vyges™ Loom, an open sign-off suite covering geometric checks, LVS, parasitic extraction, timing with signal integrity, and other physical-design workflows. It is designed to run alongside the tools you already use and provide an independent, deterministic check — not to pretend that one tool replaces an entire sign-off ecosystem. Open standards. The metadata specification behind the catalog, together with a vendor-neutral descriptor for PDKs — effectively a machine-readable specification of what a process provides and how tools consume it. Tools that explain themselves. Every Loom engine describes its own interface and capabilities. That makes it possible for an off-the-shelf AI model to discover and drive real EDA tools without fine-tuning or per-tool integration code. The intelligence plans. The deterministic tools decide. ##### The part that mattered most We taped out a chip. The Vyges™ Edge Sensor SoC went from specification through verification, implementation and tapeout using the foundation we had been building. It was sent to a real shuttle and was named a ChipFoundry Silicon2System finalist. That was an important moment for us. It is one thing to argue that silicon can be built like software. It is another to use the ideas to build and tape out actual silicon. In July, we took that work to DAC 2026, participating in the Open-Source EDA Birds of a Feather session and demonstrating a language model driving real design-rule sign-off. The model handled the reasoning and orchestration; the actual verification remained with deterministic EDA tools. But the other important signal from the first year is market interest. We have prospects who are excited about what we are building, and we are beginning to see real interest in applying Vyges to semiconductor design and development. It is still early, and there is more work to do, but we are encouraged by the conversations underway. Stay tuned — we expect to have more to share in the coming months. The sign-off work is also beginning to get its own life beyond our immediate development. The first Vyges Loom sign-off engines were released publicly in June. They are already being discussed for experimentation and evaluation by engineers working on real design flows. That is still early, but it is exactly the kind of signal we were hoping to see: open-source infrastructure moving from something we built to something other engineers want to try. ##### A major milestone for open silicon Another important step this year was bringing OpenROAD's OpenDB into the Vyges Loom suite. OpenDB provides a powerful foundation for representing physical-design data. Building Loom around that foundation is what turns it from a collection of sign-off engines into something closer to a flow — engines that share one representation of the design, hand results to each other, and can be composed into complete, executable workflows rather than run in isolation. That matters especially as we move beyond individual dies. The work is becoming a foundation for chiplet, 2.5D and 3D integration flows, where the ability to represent, inspect and verify the relationships between multiple dies and their interfaces becomes as important as verifying each die individually. Our goal is not to replace the open-source infrastructure that already exists. It is to contribute tooling that makes that infrastructure more useful, composable and executable in real flows. ##### What the year actually taught us The interesting problem was never generation. AI is already making it dramatically cheaper to produce designs, code and even complex engineering artifacts. What it does not make cheap is knowing that the result is correct. That distinction became central to our work. Make the artifacts describable. Make the tools deterministic and runnable. Make the interfaces machine-readable. Make the evidence inspectable. Then let anyone — a human, a CI system or an AI agent — compose the pieces and verify the result. That is the foundation we are building. ##### Year two The first year was about proving the thesis and building the foundation. Year two is about turning that foundation into a business. That means customer engagements and revenue, more SoCs built alongside the teams we work with, expanding the silicon we can help bring from specification to tapeout, and making Vyges Loom useful across increasingly complete design flows. It also means contributing more deeply to the open-source EDA ecosystem. The OpenDB work is an example of the direction we want to take: build on strong open foundations, contribute useful infrastructure back, and make open-source EDA capable of supporting increasingly sophisticated silicon — including chiplets and 2.5D/3D systems. The direction does not change: Build silicon like software. Make the infrastructure open where it should be open. Make verification deterministic where it has to be. And turn the foundation into real silicon, real customers and real revenue. To everyone who filed an issue, tried a build, contributed code, argued with us at a conference, or quietly cloned the catalog to see what was in it — thank you. The first year was about building the foundation. Year two is about building on it. Explore the catalog · See Vyges Loom · Read the docs · Get in touch ### Open-Source EDA Now Has a Chiplet Workflow Source: https://vyges.com/about/blog/posts/2026-08-11-open-eda-now-has-a-chiplet-workflow/ #### Open-Source EDA Now Has a Chiplet Workflow You can now describe a chiplet assembly, verify it, and see it — end to end, with open tools. Here is what that means, and what it does not. August 11, 2026 • By Shivaram Mysore Until now there was no complete open workflow for chiplet assembly verification. That changes today. Open-source EDA has covered implementation for years: RTL, synthesis, place-and-route, timing, DRC, LVS. Advanced packaging was not on that path — chiplet assembly lived entirely in commercial tools, priced as a tier above ordinary implementation, which meant the people most likely to need chiplets and least able to afford that tier had no way in. You can now describe a chiplet assembly, check that it is structurally sound, check that its die-to-die interfaces actually connect, draw it, and gate CI on all of it — with open tools, on your own machine. Here is why that matters, and what it still does not do. ##### Why chiplets, briefly If you have not had reason to care about this yet, the short version is that the industry ran into three walls at once. Size. There is a hard limit on how large a single die can be — the reticle, the maximum area a lithography scanner can print in one exposure. The largest designs have reached it. You cannot simply make the chip bigger. Yield. Defects scale with area, and they scale badly. Four small dies that each yield well are dramatically cheaper to produce than one large die of the same total area, because a defect kills a quarter of your silicon instead of all of it. Fit. Not every function wants the same process. Logic benefits from the newest, most expensive node. Analog, I/O and memory frequently do not — they work better, or merely cheaper, on an older one. A single die forces one choice for everything. Chiplets answer all three: build several smaller dies, each on the process that suits it, and join them into one package. The cost moves from the silicon into the assembly — into getting the joining right. Which is precisely the step that had no open tooling. If your work is RTL and physical design, this is becoming your problem rather than someone else's. Past the reticle limit there is no "make the chip bigger" option, so the assembly stops being something that happens after your job ends: the die-to-die interface is part of the design, and getting it wrong invalidates two perfectly good implementation runs. Advanced packaging is turning into a natural extension of digital implementation rather than a separate niche. OpenROAD's mission has largely been read as implementing a single die. OpenDB's 3D model quietly extended that foundation into advanced packaging. The tooling here is an attempt to make that capability directly usable. ##### What exists now Four commands, one binary, no GUI and no licence server: ``vyges opendb read-3dblox --input stack.3dbx --output stack.odb # read the assembly vyges opendb check-3dblox --input stack.odb # is it structurally sound? vyges opendb check-d2d --input stack.3dbx # do the interfaces connect? vyges opendb view-3dblox --input stack.3dbx --output stack.svg # what does it look like? `` Each emits JSON and exits non-zero on a violation, so they gate CI directly. It is one Rust binary — no Python, no Tcl, no interpreter, nothing to install but the file itself — and every command describes its own interface, so an AI assistant can drive it through the built-in MCP server as easily as you can from a shell. The credit for the foundation is not ours. OpenROAD's OpenDB is where the open chiplet data model came from — dies, bonding surfaces, die-to-die connections, and a stack that resolves to real positions. The division of labour is simple: OpenDB provides the data model. Vyges™ Loom provides the executable workflows built on that model. ##### The failure it was built to catch Two dies are only connected if the microbumps on their mating faces physically land on each other and carry the same signals. Get that wrong and you have a package that assembles, powers up, and does nothing. We took a working two-die assembly and made a one-character change to its description — a die that should have been flipped and mirrored was marked only as flipped. The entire 8-bit die-to-die bus now connects to nothing. verdict Structural checks ✅ 0 violations — right size, right place, correct bonding faces `check-d2d` ❌ 16 violations — every bump on both sides orphaned Structurally that assembly is perfect. Electrically it is dead. Neither die's own sign-off catches this — each die is fine. It surfaces when parts come back from the packaging house, after both have been fabricated and bonded. We are not aware of another open-source tool that checks this. We would genuinely like to be corrected on that — it is a check the ecosystem needs more than it needs our particular implementation of it. The second post has the measurements, the failure table and why the existing structural check misses it. ##### And you can see it Assemblies are hard to reason about in text, so the same command line draws them: A 2.5D assembly: two dies side by side on an interposer, seen in cross-section above and from above below. Self-contained SVG or PNG, so it commits to a repository and uploads as a CI artifact. The first post explains how to read one. ##### What is not solved Being precise here matters, because "chiplet support" is being used loosely. You cannot yet time a 3D stack with these tools — cross-die parasitic extraction and timing need database classes that do not exist upstream yet. A truly heterogeneous stack, where each die sits on a different process, cannot be fully represented either, because a design database holds one technology. That one is awkward, given that heterogeneity is the entire premise of chiplets. And there is a bigger absence. For monolithic ASICs, OpenROAD supplies the engines and OpenLane 2 / LibreLane supplies the flow. Open-source chiplet assembly has no equivalent orchestration layer yet — that is where this goes next, and the third post makes the case for why the model and the checks had to come first. Those are real gaps and we would rather name them than let the phrase imply they are done. They are also the roadmap. ##### What is solved An engineer with two dies and an assembly description can now find out whether their chiplet interface is real — before it is silicon, on their own machine, with tools they can read the source of. That matters most to the people who were furthest from this: research groups exploring heterogeneous integration, university programmes teaching packaging without a tool budget, small teams building a multi-die product for the first time, and anyone who wants to understand what their assembly description actually means rather than trusting a black box to tell them. It is narrower than "chiplet support". It is also a beginning, and it is open. ``curl --proto '=https' --tlsv1.2 -LsSf \ https://github.com/vyges-tools/cli/releases/latest/download/vyges-installer.sh | sh export PATH="$HOME/.vyges/bin:$PATH" vyges install loom `` ##### The technical detail Three companion posts cover the whole thing properly: - Describing and Checking a Chiplet Stack, With Open Tools — the assembly model: how a stack is described in 3Dblox, read into OpenDB, validated and visualized. - Your Chiplet Interface Passes Every Open-Source Check. It's Still Dead. — why structural verification is not electrical verification, and what `check-d2d` does about it. - An Open Chiplet Flow, End to End, on OpenROAD — the complete workflow, from a 3Dblox file to a CI gate, with a five-minute demo. Built on OpenROAD's OpenDB (BSD-3-Clause). `vyges-opendb` ships in the Vyges Loom open EDA suite (Apache-2.0). Corrections, counter-examples and questions are welcome — particularly from anyone who has done this in a packaging house and can tell us what we have missed. ### An Open Chiplet Flow, End to End, on OpenROAD Source: https://vyges.com/about/blog/posts/2026-08-08-an-open-chiplet-flow-on-openroad/ #### An Open Chiplet Flow, End to End, on OpenROAD Assembly description in, verdict and drawing out — with a CI gate at the end. The complete open chiplet flow, in one page. August 8, 2026 • By Shivaram Mysore This is the third post in a three-part series on open chiplet tooling. The first introduces the assembly model; the second explains why structural verification alone is insufficient. This one puts the pieces together. Every chiplet flow has to answer three questions: - How is the assembly described? — the representation layer - Is the assembly correct? — the verification layer - Can it be built? — the implementation layer This series covers the first two, which now work with open tools. The third is where this is going — and the honest state of it is step one. This post puts the first two together into one runnable flow, and is explicit about how far into the third it does — and does not — reach. ##### The part that changed Open-source EDA has a well-understood shape: RTL, synthesis, place-and-route, timing, DRC, LVS. Advanced packaging was not part of that story. Chiplet assembly, die-to-die planning and 3D verification lived entirely in commercial tools, sold as a tier above ordinary implementation — which put them out of reach of exactly the people most likely to need chiplets in the first place. That is no longer true, and the division of labour is worth stating plainly: OpenDB provides the database model. Vyges™ Loom provides the executable workflows built on that model. This is not a claim that OpenDB lacks capability. It is the opposite. OpenROAD's OpenDB is where the open chiplet data model came from — the chip and bonding-region classes, the die-to-die connections, the unfolded model that resolves a nested stack to absolute positions, the structural linter, the 3Dblox reader. Without that foundation none of what follows would be possible. What we built on top is the execution layer: commands that read an assembly, reconstruct it as native OpenDB objects, verify it, visualize it, and expose the results to CI and AI tooling. ##### The flow `` stack.3dbx + dies.3dbv + *.bmap the assembly, as text you can review │ ▼ vyges opendb read-3dblox ┌──────────────────────────────┐ │ OpenDB │ native chips, bonding regions, │ chips · regions · bumps │ die-to-die connections, bumps — │ connections · unfolded │ one model, not a parse tree └──────────────────────────────┘ │ │ │ └────────────────────────────┐ ▼ check-3dblox ▼ check-d2d structural verdict interface verdict overlap · floating dies · bonding faces unmated · misaligned bump placement net · cell mismatch │ │ └───────────────┬─────────────────────────────────┘ │ ├──► JSON on stdout → parse it, store it, diff it ├──► exit 0 / 1 → gates CI directly └──► vyges opendb view-3dblox → SVG / PNG for the review `` Every arrow above is one command, and every command is in the released binary. ##### Why "one model" is the load-bearing part It would be reasonable to assume `read-3dblox` is a parser and the checks are three programs that each read the file. They are not, and the difference is the whole architecture. `read-3dblox` reconstructs the assembly as native OpenDB objects — real chips, bonding regions, connections and bumps in the database, not a parallel structure beside it. Everything downstream then asks questions of one model: - `check-3dblox` walks the unfolded stack and reports structural faults - `check-d2d` reads the same placements to bring two bump maps into a common frame - `view-3dblox` draws the same geometry, and can carry either check's findings Three tools that each re-read the file would each hold their own interpretation of what it means — and would disagree quietly, at the worst possible moment. One database means a finding can name a bump the drawing can show you, and it means the next capability is an addition rather than a fourth parser. ##### The whole thing, in eight lines ``# once curl --proto '=https' --tlsv1.2 -LsSf \ https://github.com/vyges-tools/cli/releases/latest/download/vyges-installer.sh | sh export PATH="$HOME/.vyges/bin:$PATH" vyges install loom # per assembly vyges opendb read-3dblox --input stack.3dbx --output stack.odb # into the database vyges opendb check-3dblox --input stack.odb # structural verdict vyges opendb check-d2d --input stack.3dbx # interface verdict vyges opendb view-3dblox --input stack.3dbx --output stack.svg # the drawing `` No GUI. No X server. No licence server. One binary, four commands. ##### Gating CI Every command emits JSON on stdout and exits non-zero when it finds something, matching the rest of the Loom suite. So the gate is the command itself: ``- name: Chiplet assembly checks run: | vyges opendb read-3dblox --input stack.3dbx --output stack.odb vyges opendb check-3dblox --input stack.odb # fails the job on a structural fault vyges opendb check-d2d --input stack.3dbx # fails the job on a dead interface - name: Assembly drawing if: always() run: vyges opendb view-3dblox --input stack.3dbx --output stack.svg - uses: actions/upload-artifact@v4 if: always() with: { name: chiplet-assembly, path: stack.svg } `` The report still prints on failure — a failing job and a readable report are not alternatives. And because the drawing is a self-contained SVG, it uploads as an artifact and can be diffed between revisions like any other file in the repository. A note on how that last paragraph came to be true. An earlier draft of the previous post said these commands "gate CI like any other check." Before publishing we checked, and they did not: both exited 0 no matter what they found, so a CI job would have gone green over a dead interface — the exact failure the checker exists to prevent. That is fixed, and it is a good argument for running your own commands before writing about them. ##### The five-minute demo If you want to see why the interface check matters, this is the shortest path. It is also, we think, a good conference demo, because the audience understands the bug the moment they see it. step what you run what happens 1 `read-3dblox` + `view-3dblox` the assembly appears — two dies, bonded face to face 2 `check-3dblox` 0 violations. Everything green 3 `check-d2d` 0 violations. Interface confirmed, 8 of 8 bumps matched 4 change `MZ_MY` to `MZ` one character, in one line of the assembly file 5 `check-3dblox` still 0 violations. Everything still green 6 `check-d2d` 16 violations — every bump on both sides orphaned 7 change it back 0 violations. Job passes again Step 5 is the one that lands. The dies are the right size, in the right place, correctly oriented for bonding, and not overlapping. Structurally the assembly is perfect. Electrically the entire die-to-die bus connects to nothing. ##### Where this goes: the missing orchestrator It is worth naming what the third layer would actually look like, because there is a very good precedent for it. For monolithic ASICs, open EDA solved this years ago. OpenROAD provides the engines and the database; OpenLane 2 / LibreLane provides the flow — the orchestration that turns RTL into GDSII by sequencing those engines, carrying state between steps, and giving you one command instead of forty. Nobody hand-drives OpenROAD for a full implementation run. They run the flow. Open-source chiplet assembly does not yet have an equivalent orchestration layer. There is no open orchestrator that takes a set of hardened dies and an assembly intent and drives it through to a manufacturable, verified stack — bump map planning, die placement, interface closure, thermal and mechanical checks, and the assembly collateral a packaging house actually wants. That is the shape of the third layer, and it is where we think Vyges™ Loom goes next: the assembly flow, on OpenDB, in the same relationship LibreLane has to OpenROAD for monolithic designs. Not a replacement for LibreLane — a sibling for a different problem. LibreLane builds a die; this would build a package out of dies. We are being deliberately careful about the tense there. That orchestrator does not exist yet. What exists is the layer underneath it — a representation you can read and write, and verification you can trust — and you cannot orchestrate a flow over a model you cannot check. Crawl, then walk. This series is the crawling, and we would rather show it working than describe it convincingly. ##### What is and is not solved Solved, today, in the open: describing a 2.5D/3D assembly, reading it natively into a design database, checking its structure, checking that its die-to-die interfaces actually connect, drawing it, and gating CI on all of the above. Not solved: timing a 3D stack, which needs cross-die parasitic extraction and timing classes that do not exist upstream at the version we build against. Writing 3Dblox back out. A truly heterogeneous stack, where each die sits on a different process — a design database holds one technology, which is awkward given that heterogeneity is the premise of chiplets. That constraint is upstream's, and it is why we are careful to say "assembly description" rather than "heterogeneous stack". And the orchestrator above — the assembly flow itself. We would rather name those than let "chiplet support" imply they are done. They are also the roadmap: each one is a thing to build, in the open, on a foundation that now exists. ##### The bigger point For most of its history, open EDA has meant implementation: RTL to GDS. Advanced packaging sat outside it entirely — a domain where the tools are expensive, the vocabulary is unfamiliar to most silicon engineers, and the failure modes are silent. A meaningful part of that flow now runs on open infrastructure. OpenDB supplies the data model; Vyges Loom supplies the workflows. It is not the whole of advanced packaging, and we have been specific about which parts are missing. But an engineer with two dies and an assembly description can now find out whether their chiplet interface is real — before it is silicon, on their own machine, with tools they can read. ###### The architectural claim, said plainly Underneath the commands there is an argument, and it is the part most likely to be missed because it does not look like a feature: One semantic model, many deterministic analyses, and an execution layer over the top. Not a converter that parses a file and hands you a data structure. Not three tools that each re-read the same file and each form their own opinion of it. One database that holds what the assembly means — dies, faces, bonds, bumps, resolved positions — and independent analyses that interrogate it: structural, interface, visual, and whatever comes next. Each deterministic, each emitting JSON, each returning an exit code, so both a CI runner and an AI assistant can drive them without a bespoke integration. We think that is the right abstraction for open advanced packaging, for the same reason orchestration layers turned out to be the right abstraction for open ASIC implementation. Once OpenROAD gave the field a common database and a set of deterministic engines, the useful work moved to the layer that sequenced them. Advanced packaging is at the earlier moment: the model exists, the analyses are starting to, and the orchestration comes after — but only if the analyses agree with each other, which is exactly what sharing one model buys you. That is a beginning worth building on, and we would rather build it in the open than watch it stay behind a licence server. ##### Appendix: how it is built ###### One binary, no runtime Worth a paragraph because it changes who can actually run this. `vyges-opendb` is Rust, and it statically links OpenDB. There is no Python to install, no Tcl interpreter, no virtualenv, no dependency resolution, and no shared library to find at run time. On Linux the whole thing is an 8 MB executable whose dynamic dependencies are: ``$ ldd $(command -v vyges-opendb) libz.so.1 libstdc++.so.6 libgcc_s.so.1 libm.so.6 libc.so.6 `` That is the C runtime and zlib. Nothing else — no `libodb.so`, because it is inside the binary. The no Tcl part is specific rather than stylistic. OpenROAD is driven by Tcl, and reaching its database the usual way means bringing an interpreter along. We bind libodb directly: a pinned sparse checkout of just the database sources, compiled into a static library, with no SWIG layer and none of OpenROAD's engines. We learned that boundary the expensive way on an earlier engine, where linking a large tool to borrow one file reader dragged in an interpreter, a moving submodule and a segfault. The rule we now follow is integrate at the file format, not the library. For a packaging engineer, all of that reduces to one sentence: download a file, run it. There is no environment to get wrong, which matters when the person who needs this is not the person who maintains the Python installation. (To be clear about what this is not: it is not a criticism of LibreLane, which is Python and is the right choice for what it does. Different constraints. Ours is a single-purpose checker that has to run unchanged on a CI runner, an engineer's laptop and a build box, so a self-contained binary wins.) ###### Driving it from an AI assistant Every subcommand emits a machine-readable contract — identity, arguments, input schema, and the limits it will not exceed: ``vyges opendb check-d2d --describe `` That is what makes the tools discoverable rather than needing an integration written for each one. The Vyges CLI ships a local stdio MCP server, so an AI IDE can attach to the same binaries you run by hand: ``VYGES_MCP_PROFILE=core+opendb vyges mcp `` Connect a client and the chiplet commands are simply there, described in the tool listing: ``OpenROAD's OpenDB design DB. … DEF I/O: read-def, write-def, apply-def-template. 2.5D/3D chiplet assemblies: read-3dblox, check-3dblox, check-d2d, view-3dblox. … Passthrough: `args` are the engine's own CLI arguments. `` No plugin, no adapter, no model fine-tuned on our tools. The assistant reads what each command says about itself and drives it — and because the engines are deterministic and exit non-zero on a violation, the model proposes and the engine decides. An assistant that hallucinates a clean interface is contradicted by an exit code. We wrote about that architecture in more detail in We Didn't Train the AI. We Taught Our Tools to Explain Themselves. The chiplet commands inherit it for free, which is the point of the convention. `vyges-opendb` ships in the Vyges Loom open EDA suite — Apache-2.0, built on OpenROAD's OpenDB (BSD-3-Clause). 3Dblox is an open interchange format for 2.5D/3D assemblies. Corrections and counter-examples are welcome: if there is open tooling here we have missed, we would like to know. ### Your Chiplet Interface Passes Every Open-Source Check. It's Still Dead. Source: https://vyges.com/about/blog/posts/2026-08-05-the-chiplet-check-nobody-is-running/ #### Your Chiplet Interface Passes Every Open-Source Check. It's Still Dead. A one-character mistake in an assembly description left an entire die-to-die bus wired to nothing. Every open-source structural check reported zero violations. We built the check that catches it — `vyges opendb check-d2d` — and it ships today. August 5, 2026 • By Shivaram Mysore This is the second post in a three-part series on open chiplet tooling. The first introduces the assembly model — how a chiplet stack is described, validated and visualized. The third shows how the pieces come together into an open chiplet workflow. Every chiplet flow has to answer three questions: - How is the assembly described? — the representation layer - Is the assembly correct? — the verification layer - Can it be built? — the implementation layer This series covers the first two, which now work with open tools. The third is where this is going — and the honest state of it is step one. This post answers the second question — and shows that the obvious way to answer it is not enough. ##### The vocabulary, in four lines If you came from the first post you can skip this. If not: - A chiplet is a small chip that becomes a product only when bonded to other chips. - Every die has a front (transistors and wiring) and a back (bare silicon). For a normal chip this never matters. For a chiplet it decides everything. - Bumps are the tiny solder contacts on a die's surface. A die-to-die interface is a field of them, often thousands, on a regular pitch. - Two dies are connected when their bumps physically touch — bump 7 on one landing exactly on bump 7 of the other, both carrying the same signal. That last line is the whole article. Here is what it looks like — a 3D stack, two dies bonded face to face: The top half is a cross-section — a slice through the package, as if you sawed it in half. Note both labels reading front at the red bond line: the two active surfaces face each other, which is why the upper die had to be flipped over. The bottom half is the plan view, from above. ##### Now the problem Here is a real assembly. A compute die and a memory die, bonded face to face, joined by an 8-bit bus. Eight bumps on each side, on a 100 µm pitch. The description is a 3Dblox file — the interchange format for 2.5D/3D assemblies. It says which dies exist, where each one sits, and which surfaces bond: ``Stack: u_compute: loc: [0.0, 0.0] z: 0.0 orient: R0 u_memory: loc: [0.0, 0.0] z: 250.0 orient: MZ_MY # <- this line Connection: d2d: top: u_memory.regions.front bot: u_compute.regions.front `` `orient: MZ_MY` says the memory die is flipped and mirrored. Flipping a die over reverses the handedness of its bump field, the same way your left hand becomes a right hand in a mirror. `MZ` alone flips the face. `MZ_MY` flips it and mirrors it. Write `MZ` where you meant `MZ_MY` and the die is upside down but not mirrored. Every bump lands on the wrong side of the die. The entire bus connects to nothing. Now run the open-source structural checks on that broken assembly: ``$ vyges opendb check-3dblox --input stack.odb {"categories":[],"violations":0} `` Zero violations. The dies are the right size, they are in the right place, they do not overlap, the bond surfaces face each other correctly. Structurally the assembly is perfect. It is also dead silicon. ##### Why the existing check misses it This is not a criticism of anyone's code — it is a statement about scope, and it is worth being precise. OpenROAD's OpenDB has a `Logical Connectivity` check aimed at exactly this question. Its inner loop, from upstream's own source: ``auto it = bot_bumps.find(p); // std::map, exact integer-DBU keys if (it == bot_bumps.end()) { continue; // no bump at that precise point -> skipped, silently } `` It compares bumps that already coincide exactly and verifies they carry the same net. That is a useful check. But a bump with no counterpart is `continue`d — skipped, not reported. So it validates agreement where bumps already meet, and nothing validates that they meet at all. Its sibling function, `checkNetConnectivity`, is an empty function body. We measured what that means, on assemblies built for the purpose — and next to it, what `check-d2d` says about the same assemblies: Interface fault Structural check `check-d2d` Bump with no mating bump ✅ Pass ❌ Unmated Mating pair off by 1 nanometre ✅ Pass ❌ Misaligned Mating pair off by 5 microns ✅ Pass ❌ Misaligned Two signals swapped ✅ Pass ❌ Net mismatch Microbump mated to a C4 ✅ Pass ❌ Cell mismatch A correct interface ✅ Pass ✅ Pass Every row in that middle column is a real assembly that is dead or mis-wired, reported clean. The last row matters as much as the others: the new check agrees when the interface is right, so it is adding signal rather than noise. One honest detail about the two misalignment rows: whether a gap reads as misaligned or as two unmated orphans depends on the bump pitch. On this example — 100 µm pitch, so a 50 µm match radius — 5 µm is a near miss and gets reported as a misalignment with the distance attached. On a much finer pitch the same 5 µm would put the bump nearer its neighbour than its intended partner, and it is reported as unmated instead. Either way it is caught; the tolerance is derived from the design rather than assumed, and the report says which number it used. ##### Why this belongs in the database It would be easy to read `check-d2d` as one more CLI command. We would put it differently. A database that already models dies, bonding regions, bump maps and die-to-die connections has taken on the obligation to answer the most basic correctness question you can ask of an assembly: do the mating interfaces actually connect? Everything needed to answer it is already in there. Not answering it leaves the model describing a stack it cannot vouch for. So this is less a new feature than the logical completion of the OpenDB 3D model — the point where a description of an assembly becomes something you can be told is wrong. ##### The check we built First, the input. A bump map is the package equivalent of a DEF pin list: one line per microbump, giving its coordinates, its cell type, and the signal it carries. Each die produces one from its own implementation run, in its own coordinate system. That last point is what makes the comparison non-trivial. The two maps are not directly comparable — one belongs to a die that has been flipped, mirrored and moved. The 3Dblox assembly is what says which bump map belongs to which die and how that die is placed, so `check-d2d` compares the bump maps after applying each die's placement, not the raw coordinates as written. Two maps that look nothing alike on paper mate perfectly once placed; two that look identical may not mate at all. It emits JSON on stdout and exits non-zero when it finds something, so it gates CI directly — a failing job and a readable report are not alternatives. On the broken assembly above — the one with `MZ` where `MZ_MY` was meant: ``$ vyges opendb check-d2d --input stack.3dbx { "interfaces": [ { "connection": "d2d", "top": "u_memory.front", "bottom": "u_compute.front", "top_bumps": 8, "bottom_bumps": 8, "matched": 0, "by_kind": { "unmated": 16 }, "findings": [ { "kind": "unmated", "message": "top bump mem_rx0 (d2d_bus0) at (1800.000, 200.000) has no mating bump on the bottom die" }, { "kind": "unmated", "message": "top bump mem_rx1 (d2d_bus1) at (1700.000, 200.000) has no mating bump on the bottom die" }, ... `` Sixteen — every bump on both sides, orphaned. Eight signals leaving one die and arriving nowhere, plus eight expecting them. `matched: 0`. It catches quieter faults too. Here two nets are swapped and one bump was dropped from the map — the kind of thing that survives review because the file still looks right: ``"by_kind": { "net-mismatch": 2, "unmated": 1 }, "findings": [ { "kind": "net-mismatch", "message": "mem_rx3 carries d2d_bus4 but mates with cmp_tx3 carrying d2d_bus3" }, { "kind": "net-mismatch", "message": "mem_rx4 carries d2d_bus3 but mates with cmp_tx4 carrying d2d_bus4" }, { "kind": "unmated", "message": "bottom bump cmp_tx7 (d2d_bus7) at (900.000, 200.000) has no mating bump on the top die" } ] `` Structural check on that same assembly: 0 violations. Four fault classes, each naming the bumps involved so you can go and look: - unmated — a bump with no counterpart. A signal that leaves one die and arrives nowhere. Both sides are walked, because an orphan on the lower die is just as dead. - misaligned — a pair close enough to be intended mates but not coincident, with the distance reported. These are exactly what the existing check skips. - net-mismatch — mated bumps carrying different signals. The interface is wired, and wired wrong. - cell-mismatch — a microbump mating with a C4 (a much larger, coarser-pitch bump). Different bump types cannot mate. ##### Two things it refuses to do It will not guess how the dies are placed. Two bump maps are each written in their own die's coordinate system, and nothing in the files says how the dies sit relative to each other. Point `check-d2d` at the assembly file and it takes the placement from there; the frame it used is printed in every report: ``frame: assembly frame — top MZ_MY at (0.000, 0.000) um, die 2000.000 x 2000.000 um ; bottom R0 at (0.000, 0.000) um, die 2000.000 x 2000.000 um `` "No violations" means nothing unless you know what frame produced it. A checker that guessed an alignment and then declared everything matched would be worse than no checker at all. It will not invent a tolerance. How close is close enough to count as mating? The default is half the smaller bump pitch, derived from the maps themselves — anything nearer to a bump than that is nearer to it than to its neighbour, so a match cannot be ambiguous. On the 100 µm-pitch example above, that is 50 µm, and the report says where the number came from: ``"tolerance_um": 50.0, "tolerance_source": "derived from bump pitch" `` ##### Run it yourself Everything above is a real terminal session on a released build. Install the Vyges™ Loom suite: ``curl --proto '=https' --tlsv1.2 -LsSf \ https://github.com/vyges-tools/cli/releases/latest/download/vyges-installer.sh | sh export PATH="$HOME/.vyges/bin:$PATH" vyges install loom `` Then, on an assembly of your own: ``# read the 3Dblox assembly into a design database vyges opendb read-3dblox --input stack.3dbx --output stack.odb # structural checks: overlap, floating dies, bonding faces, bump placement vyges opendb check-3dblox --input stack.odb # the die-to-die interface: do the bumps actually mate, and carry the same signals? vyges opendb check-d2d --input stack.3dbx # draw it — cross-section and plan, one self-contained SVG or PNG vyges opendb view-3dblox --input stack.3dbx --output stack.svg `` No GUI, no X server, no licence server. Every check emits JSON and exits non-zero on a violation, so they gate CI directly. The drawings on this page were produced by that last command. If you have two dies hardened in separate runs and a bump map from each, you can also compare them directly, before either die is placed into an assembly: ``vyges opendb check-d2d --top compute.bmap --bottom memory.bmap --offset-x -120.5 --flip-x `` ##### The quieter capability underneath The checker gets the attention, but it is not the load-bearing part. That is `read-3dblox`. Unlike a format converter that stops at parsing, `read-3dblox` reconstructs the assembly as native OpenDB objects — real chips, bonding regions, die-to-die connections and bumps in the database, not a parallel data structure alongside it. The consequence is the whole point: one database then drives structural checking, interface verification and visualization. `check-3dblox`, `check-d2d` and `view-3dblox` are not three tools that each re-read the file and each hold their own opinion of what it means; they are three views of one model. That is why the drawings in this post come out of the same command line as the checks, and why a finding can name a bump that the picture can show you. It is also what makes the next capability — whatever it turns out to be — an addition rather than a fourth parser. ##### All of this is open source, and that is the point Advanced packaging is where commercial EDA is most concentrated and most expensive: chiplet assembly, die-to-die planning and 3D sign-off are sold as a tier above ordinary implementation. That changed because of OpenROAD's OpenDB — the design database at the centre of OpenROAD. The open 3D data model came out of OpenDB: the chip, bonding-region and die-to-die connection classes, the unfolded model that resolves a nested stack into absolute positions, the structural linter, the 3Dblox reader. Without OpenDB there would be nothing to build on, and we want to be plain about that: OpenDB is what made an open chiplet database exist. The division of labour, stated plainly: OpenDB provides the database model; Vyges™ Loom provides the executable workflows built on it. What we added is the layer that turns a description into a verdict: reading an assembly straight from a `.3dbx`, reading the bump maps the format points at, drawing the result, and the die-to-die interface check this post is about. We make no claim to being first to open chiplet infrastructure. OpenDB established the open data model. Our contribution is the execution layer built on that model. The narrower claim we will make, and would genuinely like to be corrected on: we are not aware of any other open-source tool that checks whether a die-to-die interface actually connects. Not whether the dies are the right size or in the right place — whether bump 7 meets bump 7 and carries the same signal. If one exists, we would like to know; it is a check the ecosystem needs more than it needs our particular implementation of it. Both projects are Apache-2.0 and BSD-3-Clause respectively. Nothing here needs a licence server, a cloud account, or a conversation with a salesperson. ##### A baseline for open advanced packaging Being clear about the boundary matters here, because "chiplet support" is a phrase being used loosely at the moment. Timing a 3D stack is not solved by any of this — cross-die timing and 3D parasitic extraction need database classes that do not yet exist upstream. Nor is a genuinely heterogeneous stack, where each die sits on a different process, since a design database holds one technology. Those are real gaps and we would rather name them than let the phrase imply otherwise. But name what does exist, because we think it is a baseline worth building on. OpenDB now provides an open data model for chiplet assemblies — dies, bonding surfaces, bump maps, die-to-die connections, and a stack that resolves to absolute positions. Vyges™ Loom adds interface verification and visualization on top of it — an assembly read natively into that model, checked at the interface, and drawn. Timing, extraction and multi-process support remain future work. But one class of expensive packaging failure — the silent one, where two dies simply do not connect — can now be caught before tape-out, with fully open tools, on your own machine, in a second. That is a smaller claim than "chiplet support". It is also a real one, and as far as we know it is new. `check-d2d`, `read-3dblox`, `check-3dblox` and `view-3dblox` ship in `vyges-opendb`, part of the Vyges Loom open EDA suite — Apache-2.0, built on OpenROAD's OpenDB (BSD-3-Clause). ### Describing and Checking a Chiplet Stack, With Open Tools Source: https://vyges.com/about/blog/posts/2026-08-02-describing-and-checking-a-chiplet-stack/ #### Describing and Checking a Chiplet Stack, With Open Tools A 2.5D/3D assembly is a description of how several dies are placed, flipped and bonded — not a design file. Here is how you write one, what can be checked about it, and how to get a drawing out, with open tools and no GUI. August 2, 2026 • By Shivaram Mysore This is the first post in a three-part series on open chiplet tooling. It introduces the assembly model: how a chiplet stack is described, validated and visualized. The second explains why structural verification alone is insufficient, and the third shows how the pieces come together into an open chiplet workflow. Every chiplet flow has to answer three questions: - How is the assembly described? — the representation layer - Is the assembly correct? — the verification layer - Can it be built? — the implementation layer This series covers the first two, which now work with open tools. The third is where this is going — and the honest state of it is step one. This post answers the first question. ##### An assembly is a different kind of file A design file — Verilog, DEF, GDS — describes one chip. An assembly describes how several chips relate to each other: which die sits where, which way up each one is, and which surfaces are bonded together. That last part is the unfamiliar one. A die has a front (transistors and wiring) and a back (bare silicon). For a normal chip this never comes up. For a chiplet it decides everything: two dies can only be joined where their surfaces meet, and which surface faces which way depends on whether the die was flipped over during assembly. The interchange format for this is 3Dblox. It comes in two files: - a `.3dbv` defines the chiplets — each die's size, thickness, and its bonding surfaces - a `.3dbx` defines the assembly — where each die instance sits, how it is oriented, and which surfaces connect Here is a complete two-die stack. The definitions first: ``ChipletDef: compute: type: die design_area: [2000, 2000] # microns thickness: 250 regions: front: # a bonding surface on the front face side: front coords: [[0,0], [2000,0], [2000,2000], [0,2000]] bmap: compute_front.bmap # the bump map for this surface memory: type: die design_area: [2000, 2000] thickness: 180 regions: front: side: front coords: [[0,0], [2000,0], [2000,2000], [0,2000]] bmap: memory_front.bmap `` Then the assembly: ``Stack: u_compute: {loc: [0.0, 0.0], z: 0.0, orient: R0} u_memory: {loc: [0.0, 0.0], z: 250.0, orient: MZ_MY} Connection: d2d: top: u_memory.regions.front bot: u_compute.regions.front `` Read that last block in English: the memory die's front surface bonds to the compute die's front surface. Face to face. The memory die sits at z = 250 µm, which is exactly the thickness of the compute die beneath it, and it is flipped (`MZ_MY`) so that its front points down into the joint. ##### Where the paths point One detail that costs people an afternoon: every relative path in these files resolves against the file that names it, not against your working directory. The `.3dbx` includes a `.3dbv` relative to itself; the `.3dbv` names its bump maps relative to itself. So the whole assembly can live in a directory and be checked from anywhere: ``vyges opendb check-d2d --input designs/stack.3dbx # works from any cwd `` `APR_tech_file` entries may also contain `*` globs and are expanded where the pattern points, and a `#!define` macro at the top of a `.3dbv` is substituted before any of that happens. ##### Reading it in ``vyges opendb read-3dblox --input stack.3dbx --output stack.odb `` That builds the chips, bonding regions, die-to-die connections and bumps in a design database, and writes it out. The database here is OpenDB, the design database at the heart of OpenROAD, and the reason any of this is possible in the open. The division of labour is simple: OpenDB provides the data model; Vyges™ Loom provides the executable workflows built on that model — reading assemblies, validating them, checking die-to-die interfaces and producing visualizations. The 3D data model is OpenDB's: the chip and bonding-region classes, the die-to-die connections, and the unfolded model, which resolves a nested stack into absolute positions so you can ask where a given bump actually ends up in the finished assembly. What the reader cannot represent, it names rather than dropping: ``read-3dblox: 1 element(s) the database cannot represent: connection soc_to_virtual (virtual, no bottom) `` That matters more than it looks. A bump map that silently failed to load would leave every bump-related check with nothing to look at — and a clean verdict to show for it. "We looked and found nothing" and "we did not look" have to be different answers. ##### Checking it ``vyges opendb check-3dblox --input stack.odb `` Seven structural checks run over the assembly: logical connectivity, floating chips, overlapping dies, unused internal surfaces, bond-region overlap and mating-surface gap, bump alignment, and alignment markers. The report names the findings, not just a count: ``{ "violations": 2, "categories": [ { "category": "Floating chips", "count": 1, "markers": [{ "comment": "Isolated chip set starting with u_compute" }] }, { "category": "Connection regions", "count": 1, "markers": [{ "comment": "Invalid connection memory_to_interposer: u_memory/front (faces TOP) to u_interposer/front (faces TOP)" }] }]} `` That second finding is a real mistake we made while building the interposer example for this series, and it is a good illustration of what the structural checks are for. We had two dies sitting on an interposer, each bonding its front to the interposer's front — and got told, correctly, that both surfaces face upward and therefore cannot mate. A die mounted on an interposer has to be flipped so its front faces down. The checker caught the modelling error before the drawing did. It is a checker, not a repairer: it annotates the in-memory database and never modifies the design. ##### The measurement that stopped us shipping something wrong Here is the part worth taking away even if you never touch a chiplet. To draw a flipped die correctly — and to check its bumps — you need to know what each orientation does to coordinates. The names look self-explanatory. `MZ` is "mirror in Z", so surely it flips the die over and mirrors it. We measured it instead, by placing a bump at a known point under every orientation and reading back where the database said it ended up: orientation where a bump at (2.84, 3.36) lands `R0` (2.84, 3.36) `MY` (47.16, 3.36) — mirrored in X `MX` (2.84, 36.64) — mirrored in Y `MZ` (2.84, 3.36) — unchanged `MZ_MY` (47.16, 3.36) — flipped and mirrored `MZ` does not mirror anything in X or Y. It flips which face points up and leaves the bump field's handedness alone. The mirror people expect from the word "flipped" comes from the `MY` component — so a face-to-face die is usually `MZ_MY`, not `MZ`. Had we reasoned from the names, we would have drawn a plausible, confident, wrong picture of every flipped die, and checked interfaces in a mirrored frame. It would have looked fine. That is the failure mode worth fearing: not the tool that crashes, but the one that answers smoothly and incorrectly. The lesson wasn't "read the documentation." It was "measure the implementation." The same instinct shows up in what the tool refuses to do. An orientation string we have not verified is rejected outright rather than processed, because the database silently treats anything it does not recognise as `R0` — inheriting that would place a die wrongly and then report the interface clean. ##### Drawing it The thing we did not expect to build. A 2D layout viewer is genuinely hard — a routed block is millions of polygons, so viewing one needs a tile server, a spatial index and a raster pyramid. A chiplet assembly is almost embarrassingly simple by comparison. A stack is a handful of dies, each a box, with a few bonding regions: tens of rectangles, not millions. So the viewer that is out of reach at layout scale is a few hundred lines here, with no server, no GUI toolkit and no X: ``vyges opendb view-3dblox --input stack.3dbx --output stack.svg vyges opendb view-3dblox --input stack.3dbx --output stack.png --scale 2 `` The output extension picks the format. SVG is exact and diffable, so it belongs in a repository or a CI artifact; PNG is what goes into a slide or a message. Both come from one layout, so they cannot drift into being pictures of different things. Two views, because one is not enough. The plan view at the bottom — the assembly seen from above — shows footprints and overhang. It cannot show stacking order, die thickness, bond gaps, or which face is bonded, and those are the entire subject. So the primary view is the cross-section at the top: a slice through the package, as if you sawed it in half and looked at the cut edge. That is where you can see the compute die at the bottom, the memory die above it, the red dashed bond line between them, and the word front on both sides of that line — the face-to-face joint. The vertical axis is stretched, and the drawing says so in its own caption. A die is millimetres across and microns thick; drawn to one scale the stack would be a line. ##### How this sits on OpenDB `vyges-opendb` is a Rust API over OpenDB with no Tcl, no SWIG, and no OpenROAD engines. It pins an OpenROAD commit, does a sparse checkout of just the database sources, and compiles a standalone static library — so the result is a single binary with no runtime library to find and nothing to configure. No Python, no interpreter, no virtualenv: on Linux it is an 8 MB executable that links the C runtime and zlib and nothing else. Download a file, run it. That boundary is deliberate, and we learned it the expensive way on a previous engine: linking a large tool to borrow one reader dragged in a Tcl interpreter, a pinned submodule and a segfault. The rule we now follow is to integrate at the file format, not the library, and to bind the database directly rather than the tools built on it. Everything above runs from one binary: ``vyges install loom # includes vyges-opendb `` ##### What is not there yet Worth stating plainly, because "chiplet support" is being used loosely at the moment. You can describe an assembly, check its structure, check its die-to-die interfaces, and draw it. You cannot time a 3D stack — cross-die timing and 3D parasitic extraction need database classes that do not exist upstream at the version we build against. Writing 3Dblox back out is not there either. And a stack whose dies sit on genuinely different processes cannot be fully represented, because a design database holds one technology — which is awkward, given that heterogeneity is the entire premise of chiplets. That one is upstream's constraint, not ours, and it is why we describe this as an assembly description rather than a heterogeneous stack. Those gaps are real, and we would rather name them than let the phrase imply they are solved. What is true today is narrower and still useful. One assembly description goes in, and three independent products come out: - a structural verdict — is the stack physically coherent? - an interface verdict — do the die-to-die connections actually connect? - a cross-sectional visualization — what does it look like? Entirely with open tools, on your own machine. That is enough to make advanced packaging a practical open-source workflow, rather than just an interchange format. `vyges-opendb` is part of the Vyges Loom open EDA suite — Apache-2.0, built on OpenROAD's OpenDB (BSD-3-Clause). 3Dblox is an open interchange format for 2.5D/3D assemblies. ### We didn't train the AI — we taught our tools to explain themselves Source: https://vyges.com/about/blog/posts/2026-07-16-we-taught-our-tools-to-explain-themselves/ #### We Didn't Train the AI. We Taught Our Tools to Explain Themselves. We didn't fine-tune a model or write orchestration code. We gave each Vyges™ Loom engine a clear, typed, machine-readable interface — and an off-the-shelf GPT-4.1 model, connected through MCP, discovered the tools and drove the sign-off flow on its own. Orchestration became a property of the interfaces, not the intelligence of a particular model. July 16, 2026 • By Shivaram Mysore When I started taping out the Vyges™ Edge Sensor SoC, my goal was simple: I wanted a sign-off flow I could trust. Like many engineers in the open silicon ecosystem, I relied on OpenSTA. It is an excellent foundation, but for the level of sign-off and optimization I wanted, there were capabilities I needed that simply weren't there. My original plan was modest: build a few missing pieces in Rust and augment the existing flow. That plan didn't last long. What began as a single Rust project gradually evolved into Vyges™ Loom — a shared architecture for sign-off and physical design optimization that now includes more than twenty engines covering timing analysis, characterization, parasitic extraction, DRC, LVS, optimization, and other sign-off tasks. The technical challenge was exciting. The developer experience challenge was much harder. ##### Twenty tools are harder to learn than one Once the first dozen engines existed, I started asking a different set of questions: - How is someone supposed to know which tool to run? - Which engine comes first? - What inputs does it expect? - Which outputs feed the next stage? I could certainly write documentation. Lots of documentation. But I've built developer tools long enough to know the uncomfortable truth: Most people don't read documentation until after they're stuck. Adding more tools would only make that problem worse. ##### A different idea Around the same time, the Model Context Protocol (MCP) was gaining traction. Instead of writing an "AI assistant" trained specifically for Loom, we tried something much simpler. Every Loom engine already had a well-defined contract: - structured inputs - structured outputs - machine-readable descriptions What if we simply exposed those contracts through MCP? - No prompt engineering. - No custom orchestration code. - No fine-tuning. - No semiconductor-specific training. The model would discover the tools the same way a developer would. If the interfaces were good enough, perhaps the model could figure out how to orchestrate them on its own. To our surprise, it worked. The model correctly identified the available engines, selected the appropriate ones, chained them together, interpreted the results, and drove the workflow without ever being trained on Loom. - We didn't teach the model semiconductor design. - We taught our tools to describe themselves. That experience eventually became the foundation for our paper, "Deterministic Core, Agent Tail", which argues that AI should plan while deterministic tools compute and verify. ##### Making it reproducible There was still one problem. When I travel to conferences, customer meetings, or workshops, - I can't depend on having a carefully prepared development environment. - Live demos are notoriously fragile. - A single missing dependency, a network hiccup, or an outdated installation can derail an otherwise great demonstration. So we asked ourselves another question: - What if anyone could watch the entire experience — from installation through orchestration — using a completely fresh environment? The result is the Vyges™ Loom Testbench. Every demonstration starts from a brand-new instance. The environment installs Loom from scratch, connects a standard GitHub-hosted GPT-4.1 model through MCP, discovers the available tools, and executes the workflow live. - No pre-training. - No hidden prompts. - No cached state. - No custom model. - Just a deterministic toolchain exposing its capabilities through standard interfaces and an off-the-shelf language model orchestrating them. That's exactly the developer experience we wanted to build. And you don't have to take my word for it — you can watch it happen. The Vyges™ Loom Testbench dashboard runs the whole thing in a clean cloud runner: Loom is installed from scratch, a stock GitHub-hosted GPT-4.1 model is pointed at the engines through `vyges mcp`, and each engine lights up as the model picks it, forms its arguments, runs it, and reads back the engine's own real sign-off result — timing met, IR-drop OK, LVS match, and so on. No pre-training, no hidden prompts, no cached state. ##### The bigger lesson This project taught me something I wasn't expecting. We often ask how to train AI to use our software. Perhaps that's the wrong question. Maybe we should spend less effort teaching models about our tools and more effort teaching our tools to explain themselves. If every engineering tool exposes clear, typed, machine-readable interfaces, then orchestration becomes a property of the interfaces — not the intelligence of a particular model. That also means today's model isn't special. Tomorrow's model should work too. And the one after that. That's a much more durable architecture. ##### See it at DAC 2026 I'll be presenting these ideas during the DAC 2026 Open Source EDA Birds of a Feather (BoF) session, including a live demonstration of MCP-driven orchestration using a completely fresh installation of Vyges Loom. If you're interested in open-source EDA, agentic workflows, or what practical AI integration looks like for deterministic engineering tools, I'd love to meet you there. ###### Learn more - Vyges Loom: https://vyges.com/products/loom/ - "Deterministic Core, Agent Tail" (paper): https://vyges.com/about/publications - Industry perspective (SemiWiki): Beyond Workflow Agents — Toward Design Intelligence in Analog EDA — an independent analysis echoing the same principle: the model plans, deterministic tools compute and verify. - Architecture overview: https://vyges.com/assets/images/loom-spine.svg - Running SemiKong locally with Loom: https://vyges.com/about/blog/posts/2026-07-09-running-semikong-local-drc/ - Live Loom Testbench: https://vyges.github.io/vyges-loom-testbench/ - DAC 2026 Events: https://vyges.com/about/events/ ### How do I use a local SemiKong LLM to drive DRC sign-off? Source: https://vyges.com/about/blog/posts/2026-07-09-running-semikong-local-drc/ #### How do I use a local SemiKong LLM to drive DRC sign-off? A semiconductor LLM can reason about DRC. It can't run it. Vyges is the layer that lets it — locally, against your own layout, with the deterministic engine as ground truth. This walkthrough drives real DRC with a locally-hosted SemiKong, end to end, on your own hardware. July 9, 2026 • By Shivaram Mysore ##### A model that reasons about DRC still can't run it Semiconductor-specific LLMs — SemiKong being one of the first openly available ones — are beginning to move from research into engineering organizations. They know the vocabulary: DRC, LVS, timing, floorplanning. But a model that can talk about a design-rule check cannot run one, and it does not know your layout or your PDK. The moment it needs your real data, it hits a wall: that data cannot leave the building. Vyges is the layer below the model. Models reason; Vyges executes. A model — SemiKong, Claude, or any other — drives the deterministic Loom engines through the open Model Context Protocol (`vyges mcp`), on your own hardware. This post walks a complete, end-to-end DRC execution loop running locally — a local SemiKong driving your DRC. New to `vyges mcp`? Start with Point Your AI IDE at Your Own Silicon Tools — Locally, No Cloud — this post builds on it, swapping a general-purpose AI assistant for a local semiconductor LLM. ##### What you'll build Everything runs on your machine. Your GDS never leaves it. The model proposes the tool call; the deterministic `vyges-drc` engine is the ground truth. Our worked example checks `spi_host_lite` — the SPI macro (`vyges-spi-lite`) from our taped-out Edge Sensor SoC. Inputs (both public): - The layout — `spi_host_lite.gds`, from the vyges-edge-sensor-soc repo (`/gds/`). - The sky130 DRC deck — the rule deck that encodes the foundry's design rules (widths, spacings, densities…) in `vyges-drc`'s grammar, from the Vyges pdk-catalog. Pass it with `--rules`. ##### 1. Get SemiKong running locally SemiKong is an open, semiconductor-specialized model (a Llama-family fine-tune). Pull it into a local runtime — Ollama or `llama.cpp` both work — so it serves on `localhost`. It runs on commodity CPU (a GPU is the upgrade); an 8B model is plenty for driving tool calls. (See the SemiKong project for the weights and a local-run recipe.) ##### 2. Install the Loom engines ``vyges install loom # fetches the open sign-off engines into ~/.vyges/bin `` `vyges-drc` is one of them — a geometric design-rule checker that reads GDS or OASIS against a rule deck. ##### 3. Register the model with `vyges model` Point Vyges at your local SemiKong. The registry stores a thin, swappable descriptor — the model is a choice, not a lock-in: ``vyges model add semikong \ --backend openai-compat \ --endpoint http://127.0.0.1:11434/v1 \ --model semikong \ --tool-calling json \ --local vyges model list # semikong (local) … `` `--local` keeps it on your hardware. `--tool-calling json` matters: local 8B models are most reliable emitting structured JSON rather than a provider-specific function-calling API, so Vyges drives them with JSON tool calls directly. ##### 4. Run the DRC loop Now let the model drive — one command: ``vyges model run semikong \ "Run a DRC check on spi_host_lite.gds against the sky130 deck (top cell spi_host_lite), then report whether it's DRC-clean or the number of violations." `` `vyges model run` runs a reason → tool-call → observe loop over the `vyges mcp` tools. The transcript below is from an actual execution of `vyges model run` against a locally-hosted SemiKong-8B: the model emitted the tool call, `vyges mcp` invoked the real `vyges-drc` engine, and the final line is the engine's result. (File paths shortened for readability.) ``── step 1 ── {"tool": "drc", "args": ["check", "spi_host_lite.gds", "--rules", "sky130-core.drc", "--top", "spi_host_lite"]} ── step 2 ── {"done": "The layout is DRC-clean with 0 violations."} The layout is DRC-clean with 0 violations. `` In step 1, SemiKong emits a structured call to the `drc` tool; Vyges invokes the real `vyges-drc` engine with exactly those arguments. In step 2, having observed the engine's verdict, the model reports it. The engine decides; the model explains. The AI proposes. The sign-off engine verifies. Execution environment (this run): ``Model: SemiKong-8B (Q4_K_M) Runtime: llama.cpp (CPU-only) Host: 2× Xeon E5-2699 v4 · 251 GB RAM · no GPU Engine: vyges-drc (Vyges Loom) PDK: sky130 Layout: spi_host_lite.gds (Edge Sensor SoC) `` ##### What you get — and why you can trust it The verdict is the deterministic engine's, produced on your own hardware. Cross-check it directly and you get the same answer: ``vyges loom drc check spi_host_lite.gds --rules sky130-core.drc --top spi_host_lite # vyges-drc — CLEAN ✓ (no violations) `` Because the deterministic engine produces the verdict, the equivalent CLI command yields the identical result — invoked by an AI model or straight from CI, the sign-off engine behaves exactly the same. A real, taped-out IP, checked by an 8B model you host yourself, matching the engine's ground truth exactly. An 8B can meander on harder, multi-step tasks — which is precisely why the design works the way it does: the deterministic engine is the ground truth, and the loop makes the model's final answer the engine's answer, not the model's guess. The model proposes; the engine verifies. One honest caveat: this walkthrough uses a representative sky130 rule deck — enough to demonstrate the loop, not a full foundry sign-off. ##### Why this is different Most AI demos for chip design stop at reasoning over text or generating RTL. This one runs a complete execution loop: a local semiconductor LLM reasons about the task, emits a structured tool call, invokes a deterministic DRC engine through `vyges mcp`, observes the engine's output, and reports the engine's verdict. The model doesn't simulate sign-off — it drives the real sign-off engine. ###### Can SemiKong run real DRC checks? Yes. When connected to `vyges mcp`, a locally-hosted SemiKong can invoke the real `vyges-drc` engine and report the engine's verdict — the walkthrough above is exactly that. ##### Why this matters - Local-first. Your layout and the model both stay on your machine. Nothing leaves the building. - Model independence. You're never tied to one AI provider — swap SemiKong for another model with a single `vyges model` entry, and your silicon flow doesn't change. AI models are replaceable; your silicon flow isn't. - Deterministic ground truth. The AI proposes; `vyges-drc` decides. Pull the AI out and the same check runs headless in CI. This lets a semiconductor organization adopt new AI models as they appear — without rewriting its verification flow or exposing proprietary RTL to an external service. ##### What's next DRC is only the first execution loop. The same architecture — reason → run → read against a deterministic engine — extends naturally to LVS, timing closure, extraction, power integrity, ECO optimization, and ultimately complete tape-out flows. The model may change over time; the execution layer stays the same. This isn't a prompt-engineering demo. It's a model-agnostic execution framework for semiconductor engineering. Replace the model, keep the execution layer, and the workflow stays the same. The thesis behind this tool — why we built it this way — is worth five minutes: EDA has quietly become a tool-management problem, so engineers spend their time orchestrating tools instead of designing chips; and most AI for chip design stops at talking about a failing report, where the point is to actually fix the design against a deterministic engine. This DRC loop is the smallest working proof of both. Then explore the Loom engines, the `vyges mcp` interface, and why AI-native silicon engineering changes the economics of getting to tape-out. Built something with this — or just exploring? Swap in a different model, point it at another engine, chain a repair, or wire the loop into CI. And whatever you try, we'd love to hear your experiences automating silicon with LLMs and Vyges — share what you built and we'll feature the best. → Share it on GitHub Discussions ### Point Your AI IDE at Your Own Silicon Tools — Locally, No Cloud Source: https://vyges.com/about/blog/posts/2026-07-06-point-your-ai-ide-at-your-silicon-tools/ #### Point Your AI IDE at Your Own Silicon Tools — Locally, No Cloud One command connects your AI assistant to real DRC, LVS, and timing engines running on your own machine. Your design never leaves your laptop. The engines stay deterministic. The agent just drives. July 6, 2026 • By Shivaram Mysore ##### The agentic moment — for silicon, on your machine AI assistants can now use tools, not just talk about them. Give an agent a set of tools and it will call them, read the results, decide the next step, and call them again — the loop that makes coding assistants feel less like autocomplete and more like a teammate. That shift is formalized in MCP, the Model Context Protocol: a standard way for agents to discover tools, call them, and consume structured results. Chip design should get the same loop. But there's a catch nobody in silicon can ignore: your RTL, your layout, your PDK are the crown jewels. Most cloud-hosted "AI EDA" products require shipping design data to their servers. For many teams — anyone under an NDA, an export rule, or a healthy sense of self-preservation — that's a non-starter. So we built the other thing. With Vyges™ Loom, your AI IDE drives real sign-off engines that run on your own machine — locally, with no cloud and no authentication. Nothing is uploaded. Nothing leaves your box. ##### One command: `vyges mcp` Loom is a suite of open, Rust-native sign-off engines — DRC, LVS, static timing with signal integrity, and more. You already install them in one shot: ``vyges install loom `` Now expose them to your AI IDE: ``vyges mcp setup `` That's it. `vyges mcp` speaks the Model Context Protocol — the open standard AI assistants use to call tools, the same protocol Claude Code and Cursor already understand — and advertises each installed engine as a tool your agent can invoke. Ask your assistant to "run DRC on this GDS against the sky130 deck installed locally" and it calls the `drc` tool, the engine runs on your machine, and structured results come back for the agent to reason about. Same for timing, LVS, and the rest. No port opened, no localhost server, no auth, no network. It's your own binaries, exposed to your own agent, on your own machine — the same trust model as any local developer tool. ##### `loom.feedback` — the agent's eyes A layout-debug loop needs more than a pass/fail. So Loom ships `loom.feedback`: one call that returns a rendered image of the layout, categorized DRC verdicts grouped by rule, and a quality score — optionally correlated against a golden reference. ``vyges mcp feedback design.gds --rules sky130.drc `` An agent calls `loom.feedback`, sees what the layout looks like and exactly what's wrong and by how much, makes an edit, and re-runs — closing the loop the way a human engineer would. It's the difference between a tool an agent can call and a tool an agent can debug with. The exact contents depend on the engine and rule deck you point it at, but the interface an agent sees is always the same shape. ##### Why local + deterministic is the whole point Two properties make this trustworthy for real silicon: - Local. Your design data stays on your machine. That's not a feature flag — it's the architecture. There is no server to send your netlist to, because the tools already live in `~/.vyges` on your box, and the server your IDE talks to is a plain local subprocess — no socket, no port. - Deterministic. The AI is a driver on top, never inside the engines. The DRC, LVS, and timing math are the same reproducible results whether an agent invokes them or your build script does. Pull the agent out and the exact same flow still runs, headless, in CI. You get the speed of an agentic loop and the reproducibility a tapeout demands. That combination — agentic on the outside, deterministic and local underneath — is the one cloud-required tools can't offer. ##### Works with the IDE you already use `vyges mcp setup` detects the AI IDEs on your machine — Claude Code, Cursor, and VS Code — and registers Loom with each, safely (it never disturbs your other tools' configuration). No plugin required — these editors speak MCP natively, and so does anything else that's MCP-compliant. Prefer to do it per project, or point a single assistant at it by hand? Those work too. Open your project, and the engines show up as tools. ##### Get started ``# 1. Install the open Loom engines (once) vyges install loom # 2. Wire them into your AI IDE (takes under a minute) vyges mcp setup # 3. Open your project in Claude Code / Cursor / VS Code # and ask your assistant to run DRC, close timing, or debug a layout. `` It's free, it's open, and it runs where your design already lives. The agentic loop has come to silicon — without leaving your laptop. Loom is Apache-2.0 and part of the Vyges toolchain. Install it with `vyges install loom`. ### Timing Sign-Off for the Open Silicon Era — and Why We Wrote It in Rust Source: https://vyges.com/about/blog/posts/2026-06-25-commercial-grade-timing-signoff-in-rust/ #### Timing Sign-Off for the Open Silicon Era — and Why We Wrote It in Rust The static timing sign-off the open-source EDA world never had — commercial-grade, CI-native, and built in Rust so it runs natively from a MacBook to an Arm64 cloud. June 25, 2026 • By Shivaram Mysore ##### The gap: open EDA had timing analysis, not timing sign-off The open-source EDA ecosystem is genuinely good now. Yosys synthesizes. OpenROAD floorplans, places, and routes. Magic and KLayout do DRC. ngspice solves circuits. OpenSTA does static timing analysis. You can take a design from RTL toward GDSII without a single proprietary license. And then you hit sign-off — and the floor gives way. Sign-off is the moment you answer, with your name on it: does this chip actually meet timing? Not "did the router think so," but the real question — worst negative slack across every path, total negative slack across the design, the single worst path, with crosstalk between neighboring nets changing the answer, and IR-drop in the power grid quietly slowing every cell it touches. That answer is what a foundry expects, what a tapeout depends on, and what — until now — you could only get from tools behind six- and seven-figure licenses. That's the gap Vyges™ Loom closes: the sign-off math you used to pay a vendor for, open, scriptable, and CI-native, under Apache-2.0. This post is about the timing spine of that stack — `vyges-sta-si`, static timing analysis with signal integrity — and the two decisions behind it that we think matter more than any single feature: why we built it, and why we built it in Rust. ##### What timing sign-off actually is: deep tree and graph processing To understand the engineering choices, it helps to see what these tools are computationally. Strip away the domain language and timing sign-off is a small family of large traversals: - Static timing analysis builds a timing graph — a directed acyclic graph over every pin and net in the design — and propagates arrival times forward and required times backward through it. On a real block that's millions of nodes and edges. The slack at every endpoint falls out of that propagation. - Parasitic extraction turns interconnect geometry into RC trees — every net becomes a tree of resistors and capacitors that the timing solve walks to get real delays. - Characterization is thousands of independent SPICE solves — one per cell, per arc, per corner — each producing a slice of a Liberty timing model. - Power integrity solves the power-distribution network as a giant sparse mesh to find where the grid sags. Two things are true of all of them. They are dominated by traversing big trees and graphs, and most of that traversal is independent — different timing endpoints, different RC trees, different cells, different corners don't need to wait on each other. In other words: this is an embarrassingly parallel workload trapped inside data structures that have to be designed, very carefully, to let the parallelism out. That last clause is the whole game. Parallelism helps enormously here — but only if the data structures, the memory ownership, and the traversal are designed for it from the first line. Bolt threads onto a graph traversal that wasn't built for them and you get data races, nondeterminism, and the kind of heisenbugs that have haunted multithreaded EDA code for decades. Which is exactly why the language mattered. ##### Why Rust We wrote the engines in Rust, and not for fashion. For a parallel, long-running, correctness-critical tree-processing workload, Rust buys three things that are otherwise expensive: 1. Fearless concurrency — data races are a compile error. Rust's ownership and borrow checker prove, at compile time, that two threads can't mutate the same data without synchronization. For an engine whose performance comes from fanning a timing graph across every core on the machine, this is transformative: you parallelize aggressively, and the class of bug that makes multithreaded EDA tools flaky and nondeterministic simply doesn't compile. Safe data-parallelism stops being a feat of heroics and becomes the default. 2. C/C++-class performance with no garbage collector. Zero-cost abstractions, no runtime, no GC pauses stuttering through a multi-hour sign-off run. The performance is deterministic — the same run takes the same time — which is exactly what you want from a tool that gates a pipeline. 3. Memory safety without giving any of that up. No use-after-free, no buffer overruns, on traversals that chase pointers through millions of nodes. Correctness you'd otherwise pay for in sanitizer runs and crash triage, delivered by the compiler. Here is the thesis in one line: by choosing Rust, correctness-under-parallelism comes from the compiler, not from us. We get to spend our effort on the timing math instead of on thread-safety archaeology. We get it, in effect, for free. ##### Portability: new platforms, for free The same choice pays a second dividend that we think is underappreciated — where these tools can run. Rust's LLVM-backed toolchain cross-compiles cleanly, and the engines are pure, dependency-light Rust. That means the same code builds and runs natively on: - x86_64 — the datacenter default. - Arm64 servers — Graviton, Ampere, and the rest of the dense, cheap-core cloud. For an embarrassingly-parallel sign-off workload, more cores per dollar is the entire ballgame, and Arm64 is where that math is best right now. - Apple Silicon (Darwin arm64) — a designer on a MacBook runs the exact engine the CI cluster runs, natively, at full speed. No "Linux x86 only" wall, no emulation tax, no second-class local experience. This is not a port we had to grind out per platform. It's a property of the language and a dependency-light design: write it once, run it native everywhere. Portability, like concurrency-correctness, comes largely for free. ###### The GPU horizon And there's a further door this leaves open. The very structure that makes this workload map onto many CPU cores — independent traversals over regular tree and graph data — is the structure that maps onto GPUs and other accelerators. We designed the engines so the parallel kernels are isolable: the hot, data-parallel inner loops are the kind of thing that can be offloaded. We are not claiming GPU-accelerated timing sign-off today — we're claiming something more durable. Rust's accelerator story is real and growing — GPU kernels in plain Rust via `rust-gpu`, compute shaders via `wgpu` — and because we built the engines parallel-by-design in a language that reaches those backends, the path to the GPU doesn't require a rewrite in another language. We bet on an architecture that doesn't foreclose tomorrow's hardware — and a language that makes following it cheap. That's the quiet payoff of the language choice: it lets a small team take advantage of the industry's hardware trajectory — Arm64 today, accelerators next — without re-tooling each time. ##### Commercial-grade, for the open world "Commercial-grade" isn't a slogan here; it's a checklist, and the timing engine meets it: - Foundry-standard formats. It reads Liberty (`.lib`) and SPEF — the same files a sign-off team and a foundry already expect. No proprietary formats, no hidden transforms. - The real metrics. WNS and TNS, and the actual worst path — not a proxy. - Signal integrity. Crosstalk-induced delay and noise from coupling between nets, accounted for — the difference between "the router thought it passed" and "it passes." - A CI gate. Standard CLI (`--json`, `--quiet`, `--verbose`) plus `--fail-on-violation`, which returns a distinct exit code so a timing violation fails your pipeline automatically. Sign-off becomes a check on every commit, not a late, manual review. It's built for the teams the proprietary model priced out: startups without seven-figure EDA budgets, platform teams standardizing CI flows, and foundries enabling reproducible PDK validation. ##### One spine, not a bundle `vyges-sta-si` doesn't stand alone — it's the timing decision point on a cross-engine data spine, a software architecture rather than an EDA bundle: ``.ext ─► vyges-extract ─► .spef ──┐ .char ─► vyges-char ─► .lib ───┼─► vyges-sta-si ─► WNS / TNS ─► resize · vt-swap · buffer-insert ─► fixed netlist └─► vyges-power ─► activity ─┬─► vyges-em-ir ─► IR-drop / EM └─► vyges-thermal ─► temp / hotspot .gds + rules ─► vyges-lvs ─► MATCH / MISMATCH `` Each engine takes one declarative job file and emits one standard artifact, and the next engine reads it directly — no glue scripts, no silent copy-drift. `vyges-char` is the parallel Liberty characterizer the open community never had; `vyges-extract` turns layout into the SPEF parasitics that make the timing real; `vyges-power` computes the switching activity that drives both a power number and `vyges-em-ir`'s IR-drop; and `vyges-lvs` proves the layout actually implements the schematic. What makes that spine real isn't magic — it's `vyges-loom`: one streamlined set of parsers and a shared design model (Liberty, SPEF, Verilog, SPICE) that every engine reads and writes. No engine ships its own half-correct Liberty reader; they all weave on the same threads. That's what kills the glue and the copy-drift — and it's what makes a new engine cheap, because it reuses the parsers and the timing graph instead of reinventing them. Which is how sign-off learned to act. The same spine that says what's wrong now fixes it — a second family of engines reads the timer's verdict and edits the netlist to close it: `vyges-resize` picks a better drive strength per cell, `vyges-vt-swap` trades threshold voltage to cut leakage while timing holds, and `vyges-buffer-insert` splits over-loaded nets. Each rides the same `vyges-loom` spine and scores every candidate on the same `vyges-sta-si` timer — they exist because the parsers and the timer already did. Analysis and optimization, one architecture, over the `vyges-layout` geometry kernel — all Apache-2.0 and runnable today. ##### Why this matters Open silicon has been climbing the stack for a decade — open cores, open buses, open PDKs, an open IP registry, open place-and-route. Sign-off was the last rung where the open path ran out and the only answer was a vendor invoice. Making commercial-grade timing sign-off open, foundry-format, CI-native — and portable and parallel-by-design so it runs natively from a laptop to an Arm64 fleet — is part of letting anyone take a design all the way from RTL to a foundry without asking permission. The language choice is how a small team delivers that and keeps pace with where the hardware is going. ##### Try it ``$ vyges-sta-si demo # instant — analyze a built-in design → WNS/TNS $ vyges-sta-si run top.sta -o top.rpt # analyze → timing report $ vyges-sta-si run top.sta --fail-on-violation # exit non-zero if WNS < 0 (CI gate) `` Already on OpenROAD, LibreLane, or OpenLane 2? `vyges-sta-si` slots in right next to OpenSTA — zero rewrite. Call the binary, point it at your existing OpenSTA script, or drop in the LibreLane step. Integration guide → docs.vyges.com. See Vyges™ Loom and the data spine, or go straight to `vyges-sta-si`. The sign-off math you used to pay a vendor for — open, in Rust, everywhere. ### VyCatalog: The Home of Free Silicon IP Source: https://vyges.com/about/blog/posts/2026-05-01-vycatalog-open-registry-for-silicon-ip/ #### VyCatalog: The Home of Free Silicon IP The first open registry for silicon IP — 125+ machine-readable IPs and growing. May 1, 2026 • By Shivaram Mysore ##### The Gap That Silicon Had PyPI for Python. npm for JavaScript. Crates.io for Rust. Maven Central for Java. Every modern software ecosystem has a place where reusable building blocks are catalogued, version-controlled, and one command away from your project. Silicon, until now, had no equivalent. If you needed a UART, an SPI controller, or an FFT block for your next chip, you had three uncomfortable options: a vendor catalog (proprietary, expensive, locked-in), an internal Excel sheet of "things our team has built before" (drift-prone, half-documented), or a deep dive through GitHub repositories hoping the README told you enough to actually integrate. None of these scale. VyCatalog closes that gap. ##### What VyCatalog Is VyCatalog is the first open registry for silicon IP. 125+ open-source silicon IPs at launch, machine-readable, free to use, and growing. Every IP block in the catalog is described by the Vyges Metadata Standard — a JSON Schema (Draft 2020-12) that captures the entire IP definition: interfaces, registers, parameters, target PDKs, integrity status, and license. The Vyges Metadata Standard turns the spreadsheet into a code artifact — registers, parameters, and interfaces version-controlled with the RTL, not maintained as separate spec docs. ##### What's In It The 125+ entries cover the building blocks of modern SoCs: - CPU cores — RISC-V (including Ibex) - System buses — APB, TileLink Uncached Lightweight (TL-UL), AXI, OBI - Peripherals — UART, SPI, I²C, GPIO, interrupt controllers - DSP and math — Fast Fourier Transform (FFT), CORDIC - Memory — SRAM macros, register files - Mixed-signal — analog-to-digital converters (ADC), temperature sensors …and more. Browse the full catalog — the list grows as new IPs are indexed and verified. ##### The IP Nutrition Label Every entry in VyCatalog ships with what we call an IP Nutrition Label — borrowed from FDA food labels for instant comprehension. You wouldn't open every cereal box at the grocery store and taste it before buying. You read the label. In silicon, "tasting" means reading the RTL — every interface, every register, every state machine. Engineers need (System)Verilog fluency to evaluate. AI tools burn tokens parsing it from scratch every time. Labels avoid both costs. The label normalizes across IPs the same way an FDA food label normalizes "salt" vs "sodium bicarbonate" — different underlying source, one readable surface. Bus, registers, timing, integrity status, license, target PDK — all scannable in seconds. Engineers scan it; AI agents consume it directly. ##### Why It's Open A proprietary registry would cap supply; an open one compounds it. The economic logic is straightforward: if Vyges ran the registry as a paid product, supply would be bounded by who pays Vyges. Run it open, and supply is bounded by who shows up — a far larger set. Every IP that lands in the catalog makes the next chip faster. The public registry is free, and stays free. For organizations with proprietary, embargoed, or licensed IP that cannot sit in a public catalog, we offer VyCatalog Enterprise — the same registry engine and the same metadata standard, deployed inside your perimeter (on-premise, your cloud, or Vyges-managed). One engine, one metadata model, two configurations. The public catalog scale-tests the enterprise deployment; fixes flow in both directions; there is no fork. ##### How To Use It Today - Browse — go to vyges.com/products/vycatalog/ and click any IP. The label tells you what you're getting in seconds. - Integrate — clone the repository, drop the RTL into your design, follow the metadata's interface contract. - Contribute — got an open-source silicon IP? Apply the Vyges Metadata Standard and submit it. The standard itself is open. Today this happens through Git and the catalog's web UI. Coming soon: Vyges CLI — the package manager for silicon IP, same pattern as `npm` for npmjs.org or `pip` for PyPI. Vyges CLI is in early access; contact us for access. ##### What's Next The next post in this series will show how Vyges itself used VyCatalog to compose a fab-ready SoC in weeks — eight verified blocks from the registry, integrated, verified, hardened, and submitted to fab. We will publish that post once the contest submission goes through. ##### Closing Software has PyPI, npm, and Crates.io. Until VyCatalog, silicon had nothing equivalent. That is changing. → Browse VyCatalog → Read the Vyges Metadata Standard → Vyges CLI early access ### VyBox Lite: Cloud-Native Silicon IP Development with GitHub Codespaces Source: https://vyges.com/about/blog/posts/2025-08-18-vybox-lite-codespaces/ #### VyBox Lite: Cloud-Native Silicon IP Development with GitHub Codespaces Zero setup. Full power. AI-assisted silicon IP development in your browser. A pre-configured, browser-based environment for silicon IP design — powered by GitHub Codespaces + AI. August 18, 2025 • By Shivaram Mysore ##### The Cloud Development Revolution Hits Silicon IP For years, silicon IP development has been shackled to local workstations with complex toolchains, license servers, and environment setup headaches. Every new team member meant days of configuration. Every tool update risked breaking existing workflows. What if you could spin up a complete silicon IP development environment in seconds, with zero setup, from any device? Today, we're excited to announce VyBox Lite — a cloud-native development environment that brings the full power of silicon IP development to GitHub Codespaces, complete with AI assistance and pre-configured EDA tools. ##### 🚀 What is VyBox Lite? VyBox Lite is a browser-accessible development environment specifically designed for silicon IP and chiplet projects. It's built on GitHub Codespaces and comes pre-configured with everything you need to start building production-ready IP blocks immediately. ###### Key Features: - 🖥️ Zero Installation: Runs entirely in your browser - ⚡ Instant Setup: Pre-built with all EDA tools and dependencies - 🤖 AI-Ready: Integrated LLM support with GitHub Models - 🔧 Production Tools: Yosys, Verilator, Icarus Verilog, GTKWave - 📦 Vyges Integration: Built-in metadata schema and AI context - 🌐 Cross-Platform: Works on macOS, Windows, Linux, Chromebook ##### 🎯 The Development Workflow VyBox Lite streamlines the entire silicon IP development process into a simple, visual workflow: Vyges IP Development Workflow - From template to production-ready silicon IP The process is simple: - Create Repository: Use the Vyges IP Template to scaffold your project - Choose Your Environment: Local development or VyBox Lite (GitHub Codespace) - Develop with AI: Leverage integrated LLM assistance for RTL design - Generate Outputs: Produce RTL, testbenches, documentation, and synthesis reports ##### 🛠️ What's Inside VyBox Lite? ###### Pre-Configured Development Environment When you launch VyBox Lite, you get a complete development environment with: - 📦 EDA Tools: Yosys, Verilator, Icarus Verilog, GTKWave - 🐍 Python Ecosystem: Python Cocotb, and verification frameworks - 🔧 Build Tools: Make, Python3 and automated workflows - 📝 Documentation: Pre-configured templates and generators - 🤖 AI Integration: LLM CLI with GitHub Models support ###### AI-Assisted Development VyBox Lite comes with built-in AI capabilities via two complementary approaches: GitHub Copilot (Inline Assistance): - Real-time code suggestions as you type - Context-aware completions for RTL and testbench code - Integrated with VS Code in the browser GitHub Models (CLI Access): - Command-line access to advanced LLMs via the `llm` CLI - Perfect for generating complex RTL modules and testbenches - Available models include GPT-4.1, Claude, and others ``# Generate RTL with AI assistance llm -m github/gpt-4.1 "Generate a Verilog module for an AXI4-Lite slave interface" # Create testbenches llm -m github/gpt-4.1 "Write a SystemVerilog testbench for a 32-bit counter" `` Note: For public/free repos, GitHub Copilot and Codespaces may be limited by credits provided. Check GitHub pricing for more details ###### Vyges Integration Every VyBox Lite environment includes: - 📋 Metadata Schema: Pre-loaded Vyges metadata specification - 🤖 AI Context: `.vyges-ai-context.json` for domain-specific assistance - 🔗 Template Integration: Seamless connection to Vyges IP Template - 📊 Reporting: Automated generation of standardized reports ##### 💰 Pricing and Availability (Guidance only) ⚠️ Important: Pricing is set by GitHub, not Vyges. We provide VyBox Lite as a free template — you pay GitHub directly for Codespaces usage. VyBox Lite leverages GitHub Codespaces' flexible pricing model: Option vCPUs RAM Free Tier Best For 2-Core 2 4 GB ✅ 60 hours/month Light workloads, exploration 4-Core 4 8 GB ⚠️ Counts double Heavier builds, faster performance 8-Core 8 16 GB ❌ Pay-as-you-go Enterprise workloads Free tier applies to public repositories only. After the included hours, you're billed at: - 2-core: $0.18/hour - 4-core: $0.36/hour - 8-core: $0.72/hour Check GitHub pricing for more accurate information ##### 🚀 Getting Started ###### Launch VyBox Lite Click one of these badges to launch your environment: ###### Quick Start Commands Once your Codespace is running, you can check your pre-configured tools `yosys -V && verilator --version` or use the GitHub CoPilot chat "Use Vyges Connventions to write a SystemVerilog testbench for a 32-bit counter" That's it! You're ready to start building silicon IP with AI assistance. ##### 🎯 Use Cases ###### Academic Research - Zero setup for students and researchers - Consistent environments across teams - AI assistance for learning and exploration ###### Open Source Development - Collaborative development without environment conflicts - CI/CD integration with GitHub Actions - Standardized workflows for contributors ###### Enterprise Teams - Onboarding acceleration for new team members - Tool standardization across development teams - Cost-effective scaling with pay-as-you-go pricing ##### 🔮 The Future of Cloud-Native Silicon Development VyBox Lite represents a fundamental shift in how we approach silicon IP development. By moving to the cloud, we're enabling: - 🌍 Global Collaboration: Teams can work together regardless of location - ⚡ Instant Scalability: Spin up environments as needed - 🤖 AI Integration: Seamless AI assistance throughout the development process - 📊 Standardization: Consistent environments and workflows - 💰 Cost Optimization: Pay only for what you use This is just the beginning. As we continue to develop VyBox Lite, we're working on: - 🔗 Multi-User Support: Team environments with shared resources - 📦 Private Registries: Enterprise-grade IP management - 🤖 Advanced AI: More sophisticated AI-assisted design capabilities - 🔧 Tool Integration: Support for commercial EDA tools ##### 🎉 Try VyBox Lite Today Ready to experience cloud-native silicon IP development? Launch VyBox Lite now and start building production-ready IP blocks in minutes, not days. ➡️ Launch VyBox Lite (2-Core) ➡️ Launch VyBox Lite (4-Core) ➡️ Learn More About VyBox ➡️ Explore the IP Template "VyBox Lite brings the cloud development revolution to silicon IP. No more setup headaches, no more environment conflicts — just pure development power, available instantly from anywhere." About the Author: Shivaram Mysore is the Founder and CEO of Vyges. With over two decades of experience at the intersection of software, standards, open-source and platform infrastructure, Shivaram is passionate about bringing modern software engineering practices to silicon development. ##### 📬 Stay Updated Don't miss our latest insights on cloud-native silicon development and VyBox updates. Subscribe to our RSS feed for automatic updates: Subscribe via RSS | 📧 Contact us | 👀 Follow us on X, LinkedIn --- ## Company & docs ### Documentation Source: https://vyges.com/docs/ #### Documentation The standards, the tools, and the open IP behind Vyges silicon. API and Tool Docs Metadata Standard ###### Vyges Metadata Standard The schema that describes every Vyges IP — interfaces, registers, parameters, and more — with an interactive schema viewer. Explore the standard → ###### PDK Specification The descriptor schema for presenting PDKs consistently across the Vyges stack — with its own schema viewer. Explore the spec → ###### API and Tool Docs Install the Vyges CLI, the full command reference, and usage guides. Read the docs → ##### Resources ###### GitHub Repositories Explore the open IP catalog and developer tooling on GitHub. IP catalog — vyges-ip → Tools — vyges-tools → ###### Community Join discussions and get help from the community. Join Community → ###### Contact Support Get help and ask questions directly. Contact Us → ### About Source: https://vyges.com/about/ #### About Vyges We sell silicon. AI helps us build it dramatically faster than anyone else. Vyges builds and licenses fab-ready SoC IP, commissions silicon for buyers, and operates the first open registry for silicon IP — with an open execution layer any AI model can drive locally. Silicon is how we monetize; AI and the open toolchain are how we ship it faster. Talk to us about silicon Browse VyCatalog ##### Why We Exist Vyges sells fab-ready SoC IP — complete, integrated, and proven — so companies don't have to spend millions and 6–9 months outsourcing integration just to get to tapeout. Most SoC programs spend $2–5M and 6–9 months on outsourced integration just to reach tapeout. We replace that step with fab-ready SoC IP delivered in weeks. The way we ship that fast is by treating silicon delivery like software — and letting AI drive it: an open registry, a machine-readable metadata standard, deterministic engines any AI model can run locally, and automated promotion to fab-ready artifacts. AI orchestrates the flow; deterministic engines do the work. The infrastructure is internal leverage; the silicon is what we sell. ##### What We Offer Two ways customers buy from us, anchored on an open registry that the silicon ecosystem is converging on. ###### Public registry (open, free) VyCatalog — the first open registry for silicon IP, 150+ IPs and growing. Built on the Vyges Metadata Standard. ###### Silicon (the product) Fab-ready SoC IP and commissioned silicon. Replaces $2–5M and 6–9 months of outsourced integration with weeks-not-months delivery. ###### VyCatalog Enterprise Private catalogs that bring proprietary IP into the same metadata standard. Same engine as the public registry; customer-deployed. ###### Internal generators (leverage) Automated SoC generation and CI compound to deliver fab-ready silicon faster than anyone else. Internal infrastructure, not a product. View all products → ##### How We Make Money Two ways customers engage with us today: silicon products, and VyCatalog Enterprise. Both compound with the open registry — the more IP indexed publicly, the cheaper and faster every Vyges silicon program runs, and the more enterprise buyers depend on the same metadata standard for their own IP. Product 1 ###### Silicon Fab-ready SoC IP licensing and commissioned silicon. One revenue motion, differentiated by customer stage. Replaces $2–5M and 6–9 months of outsourced integration with weeks-not-months delivery. Product 2 ###### VyCatalog Enterprise Private catalogs for buyers managing proprietary, embargoed, or licensed IP at scale. Same engine as the public registry, customer-deployed. Replaces spreadsheet-based IP tracking and retrofitted PLM with a silicon-native registry. Source-controlled metadata, customer-deployed (on-premise, your cloud, or Vyges-managed) — multi-target across ASIC, FPGA, and chiplet. The flywheel: VyCatalog Enterprise revenue compounds with public-registry growth — every IP indexed in the public catalog increases buyer choice and lowers integration cost for Vyges silicon programs, and every silicon program reinforces the enterprise tier's gravity. "Vyges builds silicon products; the registry and infrastructure are how we compound speed, reuse, and trust across generations of chips." ##### Our Architecture IP Creation → Metadata & Discovery → Integration & Deployment This structure enables scalable workflows, ecosystem-wide reuse, and forward-compatible extensibility. Learn More ##### Who We Serve Vyges delivers outsized ROI for teams building custom silicon, FPGAs, and IP portfolios. Whether you're taping out a new chip, scaling an internal IP library, or onboarding external vendors, Vyges creates leverage across your entire workflow. ###### For Semiconductor & Systems Companies High-leverage value for every chip program - • Replace months of outsourced integration with fab-ready SoC IP delivered in weeks - • Slash backend tool overhead and QA rework - • Ensure consistency and reuse across internal/external teams - • Works with your existing PDKs, EDA licenses, and tool flows - • Our cost is a rounding error—your gain is measurable "A single tapeout budget runs into millions. Vyges delivers payback within days, not quarters." ###### For Chip Startups & Fast-Moving Teams Accelerate time-to-IP and tapeout - • Start from best-practice templates - • Automate validation and integration - • Focus engineering effort where it matters most - • Ship IP that's clean, trusted, and reusable ###### For Academic & Research Labs Teach real-world IP flows with open tooling - • Free and open-source tooling for teaching - • Realistic RTL-to-tapeout workflows - • Train students on metadata, versioning, and reuse ##### Our Story Vyges was founded by a software technologist frustrated by the inefficiencies in the semiconductor world. While modern software development enjoys standardized tooling, seamless automation, and global collaboration, the silicon IP ecosystem remains fragmented, manual, and often vendor-locked. We set out to change that. Vyges brings software engineering practices — metadata standards, automation, templates, CI, and AI-agent-friendly tooling — to silicon design. We didn't start with fabs or tapeouts. We started with code, metadata, and the belief that silicon design should be reproducible, modular, and open. Today, Vyges is the execution layer for AI-native silicon engineering — any AI model can drive our open, deterministic engines against a company's own IP, locally, to design and verify chips. We help teams, from chip startups to major semiconductor companies, build better silicon, faster. ##### Why Now Several trends — each independently real — combine to make this the right moment to ship AI-native silicon-as-a-product on top of an open metadata standard. ###### AI agents change the buyer Claude, Cursor, and other AI agents pre-screen products for human buyers via machine-readable surfaces. Silicon IP that ships with structured metadata gets discovered; opaque IP gets ignored. The Vyges Metadata Standard is built for that shift. ###### Models reason — but can't execute Every semiconductor team is adopting an AI model, and none can make it run their flows or respect their data boundary. That gap — execution, private knowledge, and local governance — is exactly what Vyges supplies. A model reasons; Vyges executes. ###### AI is collapsing the value of tool expertise Teams are staffed around tools — a PrimeTime engineer, a Calibre engineer, an Innovus engineer — not around chips. One interface any AI model can drive ends that tax: engineers work on the chip, not on fourteen tool dialects. ###### The open-silicon stack matured Sky130, GF180, OpenLane, OpenROAD, Yosys, RISC-V cores — the open-source silicon stack is production-grade for real tapeouts. The plumbing is now ready for products on top of it. ###### The chiplet era is real UCIe, Intel Foundry's chiplet roadmap, AMD/Apple's chiplet shipping — silicon programs are now composed of pre-integrated dies. Composition needs metadata; metadata needs a standard; the standard needs a registry. ###### Sovereign chip initiatives Government-backed silicon programs across the US, EU, and Asia are scaling domestic capacity faster than the legacy IP-vendor + integration-services pipeline supports. Outcome-based fab-ready IP delivery is the alternative. ##### The Team Built at the intersection of software and silicon. Vyges is founded on a belief that modern hardware development deserves modern tools. We actively collaborate with chip designers, startups, and tool vendors to bring this vision to life. SM ###### Shivaram Mysore Founder & CEO A serial entrepreneur with over 20 years of experience at the intersection of software, standards, and platform infrastructure. Shivaram has held leadership roles at Sun Microsystems, Microsoft, and Infoblox, and has been instrumental in shaping open standards through global organizations like W3C, ANSI/ISO, and the Open Networking Foundation (ONF). With deep experience across software, infrastructure, and standards, Shivaram brings a rare cross-industry perspective — a unique outside-looking-in approach to modernizing silicon development, open tooling, and trust infrastructure. ###### Experience - • Sun Microsystems - • Microsoft - • Infoblox - • W3C, ANSI/ISO, ONF (Open Standards) ###### Expertise - • Platform Design - • Open Standards - • Infrastructure Architecture - • Developer Ecosystems - • Cross-Industry Innovation ##### Support our open-source work VyCatalog, the Vyges Metadata Standard, the open IP catalog, and the tools around them are open-source under Apache 2.0. If your team relies on this work — or wants to see more of it — sponsorship helps fund maintenance, new IP onboarding, and standards stewardship. Sponsor on GitHub → ##### Join us in shaping the future of silicon IP Whether you're building chips, teaching students, or enabling tools—we'd love to work together. View Products Contact Us Visit VyCatalog ### Blog Source: https://vyges.com/about/blog/ #### Vyges Blog Latest insights, updates, and technical content from the Vyges team Discover how to build, test, and deploy reusable silicon IP with modern engineering practices. ##### Recent Posts ###### A Floorplan Without the Village August 31, 2026 • By Shivaram Mysore Getting a floorplan out of an open flow has meant installing the whole flow. We took the six steps that build one and shipped them as static binaries you can point at your own netlist. Four die sizes explored in under a minute — and on a block whose taped-out DEF we can check against, the rows and tracks match exactly. Read more → ###### Context, Capability, Correctness: Three Bets on Trusting an AI Agent August 12, 2026 • By Shivaram Mysore Cloudflare and Spotify both shipped agent platforms this month, and each answers a different question about why an AI agent cannot be trusted to act on its own. There are three such questions — and almost nobody is working on the third. Read more → ###### Vyges: First Year Anniversary August 11, 2026 • By Shivaram Mysore One year ago today, Vyges launched with a claim: silicon should be built like software. A year on, the catalog is open, the sign-off engines are open, and a chip has gone from specification to tapeout using the foundation we set out to build. Read more → ###### Open-Source EDA Now Has a Chiplet Workflow August 11, 2026 • By Shivaram Mysore Advanced packaging has been the part of silicon design that open tools could not reach. That changed. You can now describe a chiplet assembly, check that it is structurally sound, check that its die-to-die interfaces actually connect, draw it, and gate CI on all of it — with open-source tools, on your own machine. Read more → ###### An Open Chiplet Flow, End to End, on OpenROAD August 8, 2026 • By Shivaram Mysore Assembly description in, verdict and drawing out, with a CI gate at the end. The complete open chiplet flow in one page — plus the five-minute demo where a one-character change kills an entire die-to-die bus and the structural checks stay green. Read more → ###### Your Chiplet Interface Passes Every Open-Source Check. It's Still Dead. August 5, 2026 • By Shivaram Mysore Two chips bonded together are only connected if the bumps on their mating faces land on each other and carry the same signals. A one-character mistake left an entire 8-bit die-to-die bus connected to nothing — and every open-source structural check reported the assembly clean. So we built the check that catches it. Read more → ###### Describing and Checking a Chiplet Stack, With Open Tools August 2, 2026 • By Shivaram Mysore An assembly is not a design file — it is a description of how several dies are placed, flipped and bonded. OpenROAD's OpenDB made that describable in the open. Here is how to write one, check it, and draw it as a cross-section, from one command line with no GUI. Read more → ###### We Didn't Train the AI. We Taught Our Tools to Explain Themselves. July 16, 2026 • By Shivaram Mysore No fine-tuning, no orchestration code. We gave each of Vyges Loom's twenty-plus sign-off engines a clear, typed, machine-readable interface — and an off-the-shelf GPT-4.1 model, connected through MCP, discovered the tools and drove the sign-off flow on its own. Orchestration became a property of the interfaces, not the model — so today's model isn't special, and tomorrow's works too. Read more → ###### How do I use a local SemiKong LLM to drive DRC sign-off? July 9, 2026 • By Shivaram Mysore A semiconductor LLM can reason about DRC — it can't run it. This walkthrough points a locally-hosted SemiKong at real DRC on your own hardware, with real captured output on a taped-out IP: the model proposes the tool call, the deterministic `vyges-drc` engine is the ground truth, and nothing leaves your machine. Read more → ###### Point Your AI IDE at Your Own Silicon Tools — Locally, No Cloud July 6, 2026 • By Shivaram Mysore Install the Vyges Loom engines, run one command, and your AI IDE — Claude Code, Cursor, or VS Code — can drive real DRC, LVS, and timing sign-off on your own machine. No cloud. No upload. No auth. The engines stay deterministic; the agent just drives. Read more → ###### Timing Sign-Off for the Open Silicon Era — and Why We Wrote It in Rust June 25, 2026 • By Shivaram Mysore Open EDA gave the world synthesis, place-and-route, and DRC — but not commercial-grade timing sign-off. We built it: WNS/TNS with signal integrity, foundry-standard formats, CI-native. And we wrote it in Rust, so it runs natively everywhere from Apple Silicon to Arm64 cloud — with a parallel-by-design architecture that doesn't foreclose the GPU. Read more → ###### VyCatalog: The Home of Free Silicon IP May 1, 2026 • By Shivaram Mysore Software has PyPI, npm, and Crates.io. Until VyCatalog, silicon had nothing equivalent. 125+ open-source silicon IPs, machine-readable, free, and growing. Read more → ###### VyBox Lite: Cloud-Native Silicon IP Development with GitHub Codespaces August 18, 2025 • By Shivaram Mysore Introducing VyBox Lite — a browser-accessible development environment that brings the full power of silicon IP development to the cloud, complete with AI assistance and pre-configured EDA tools. Read more → ###### Getting Started with Vyges: Build Your First Silicon IP Block August 11, 2025 • By Shivaram Mysore Learn how to create, test, and deploy reusable silicon IP blocks using Vyges. From template to working IP with AI assistance, CI/CD, and automated reporting. Read more → ###### Introducing Vyges: Metadata-Driven Infrastructure for Reusable Silicon IP August 11, 2025 • By Shivaram Mysore Structured like software. Verified by automation. Reused with confidence. Vyges brings modern software engineering practices to silicon IP development. Read more → ##### Stay Updated Follow our blog for the latest updates on: - Platform features and improvements - Technical tutorials and guides - Industry insights and trends - Community highlights and case studies ###### Stay Connected Get the latest updates delivered to your inbox or RSS reader. Subscribe via RSS 📧 Contact Us Follow us on and ### Publications Source: https://vyges.com/about/publications/ Research #### Publications Papers from the Vyges team on open silicon sign-off and AI-native chip design. Systems architecture ##### Vyges Loom: A Shared Data-Spine Architecture for Open Sign-Off and Physical Design Optimization An open (Apache 2.0) architecture that brings sign-off-quality timing closure — and the optimization that closes it — to open process nodes, unifying analysis, optimization, and verification over one shared data model. Shivaram Mysore, Vyges · Zenodo, 2026 · CC BY 4.0 Read the paper → doi:10.5281/zenodo.21437930 AI & orchestration ##### Deterministic Core, Agent Tail: A Verify-Before-Ship Architecture for Orchestrating Open Silicon Sign-Off A reliability pattern for applying language models to sign-off-grade chip design: a large deterministic core of trusted engines with a thin agent tail, governed by a verify-before-ship gate that never ships a result it cannot confirm. Shivaram Mysore, Vyges · Zenodo, 2026 · CC BY 4.0 Read the paper → doi:10.5281/zenodo.21438246 ### Events Source: https://vyges.com/about/events/ Events #### Where to find Vyges Where the Vyges team is showing up next — and recordings and write-ups from where we have already been. ##### Upcoming ORConf 2026 · Talk ###### Reuse You Can Check: An Open IP Registry and an Independent Sign-Off Suite Sept 11–13, 2026 · Zebrastraat, Ghent, Belgium Shivaram Mysore presents at ORConf 2026, the FOSSi Foundation’s open silicon conference. Reusing an IP block means trusting someone else’s claims about it. The talk covers the two halves of making those claims checkable: Vyges VyCatalog™, an open machine-readable registry for silicon IP with validated metadata for RTL interfaces and PDK targets, and Vyges Loom™, an open sign-off suite — geometric DRC, LVS, RC extraction, and static timing with signal integrity — that lets you verify the claims yourself instead of taking them on faith. See the talk on the ORConf program → About ORConf 2026 → We are usually at DAC and the open-silicon conferences, and we are happy to talk to a team that is evaluating open EDA. Get in touch → ##### Past DAC 2026 · Panel ###### From “How” to “What”: Rethinking Skill Sets in the Age of AI Tue, July 28 · 8:30–9:10 PM · Room 104C Shivaram Mysore joined the Open-Source EDA Birds of a Feather panel as the industry voice, alongside panelists from Arizona State, Brown, Columbia, ETH Zurich and Silimate. The question on the table: if AI can build what you describe, what should engineers be learning instead? Our answer — AI makes generating a design cheap, and makes proving it correct the skill that matters. See the full BoF agenda → DAC 2026 · Birds of a Feather ###### Using a Semiconductor LLM to Drive Real DRC Sign-Off Tue, July 28 · 9:10–9:30 PM · Room 104C A lightning talk by Shivaram Mysore in the Open-Source EDA Birds of a Feather session (AM110) at the 63rd Design Automation Conference (DAC), 2026 — a live run showing an LLM driving real DRC sign-off, with the checking left to deterministic tools. Watch the talk on YouTube → View on the DAC program → About the BoF → 2026 · Hackathon ###### ICLAD Hackathon July 2026 Vyges competed in the ICLAD Hackathon as Team 22, entering both the cloud and on-site tracks. ### Contact Source: https://vyges.com/contact/ #### Contact Us Let's build AI-native silicon together. Have questions, ideas, or want to partner or contribute? We'd love to hear from you. Discuss a silicon engagement Join Community ###### Community Support Join discussions, ask questions, and connect with the community GitHub Discussions ###### Report Issues & Features Found a bug or have a feature request? Report it in our community repo GitHub Issues ###### Private Contact For private inquiries, partnerships, or sensitive matters Contact Privately ###### Schedule a Call Book a meeting with our team to discuss your needs Schedule Meeting ###### Request Demo See Vyges tools in action with a personalized demo Request Demo ###### Media Inquiries Press, interviews, and media coverage requests Media Contact ###### Partnerships EDA vendors, foundries, and toolchain providers Partnership Inquiry ##### Additional Resources Explore our documentation, community resources, and learn more about Vyges ###### Documentation Comprehensive guides, tutorials, and API documentation Read Documentation → ###### Community & Discussions Share your automations and experiences with LLMs and Vyges, ask questions, and connect with other builders. Join the Discussions → ###### Blog Latest news, tutorials, and insights from the Vyges team Read Blog →