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:

1. How is the assembly described? — the representation layer
2. Is the assembly correct? — the verification layer
3. 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 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.