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.

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).