Chiplets are everywhere in roadmaps—CPUs, accelerators, memory stacks, advanced packaging. Protocols like UCIe promise modular, interoperable multi-die systems.
But once you try to actually build a chiplet system, a different reality appears:
Chiplets are easy to talk about—and surprisingly hard to make practical.
At WIOWIZ, we set out to explore that gap by building a working, readable, SystemVerilog-based die-to-die (D2D) reference implementation — not production IP, but something engineers can study, simulate, and extend.
Why Chiplets Are Still Hard to Experiment With
Most chiplet resources fall into one of these buckets:
- Academic implementations in unfamiliar languages
- PHY-heavy designs that hide protocol behavior
- Commercial IP that can’t be inspected or modified
What’s missing is a low-friction starting point — something that lets engineers see what really happens during link bring-up, negotiation, and data movement.
That’s the problem we focused on.
What We Built (And What We Didn’t)
We intentionally did not try to build a compliant or tapeout-ready UCIe IP.
Instead, we built:
- A UCIe-inspired D2D link focused on behavior, not certification
- A clean SystemVerilog RTL design, easy to read and modify
- A minimal verification setup designed to expose—not hide—failures
This choice surfaced issues that rarely show up in high-level discussions.
One early simplification we made looked harmless—but it completely hid a class of integration bugs.
👉 That specific failure (and why it happened) is explained here:
Chiplets, Made Practical
Where Theory Meets Reality
The datapath itself wasn’t the hardest part.
The real challenges showed up in:
- Link bring-up assumptions
- Sideband coordination
- Observability during partial failures
These are the kinds of problems you don’t see in protocol diagrams—but they dominate real chiplet integration work.
We deliberately left parts of the system “imperfect” so engineers can see where real-world designs tend to break first.
Why Verification Matters More Than Bandwidth
Most chiplet discussions focus on throughput numbers.
In practice, the harder question is:
How do you know both dies agree on what just happened?
Even a basic verification setup reveals surprising corner cases during early bring-up. That insight is one of the main motivations behind this reference design.
Why This Is Just the Beginning
This foundation enables practical experiments like:
- CPU ↔ memory chiplets
- CPU ↔ CPU communication
- Multi-die meshes combining compute, memory, and accelerators
Each configuration exposes different system-level issues—none of which appear in single-die designs.
Full Engineering Details (Canonical)
This dev.to post intentionally skips:
Internal module breakdowns
Design trade-offs
What failed during early iterations
Why certain simplifications were reversed
If you want the actual engineering story, read the full article here:
Takeaway
Chiplets won’t become mainstream through specs alone. They become practical when engineers can experiment, break things, and learn.
This work is about making that experimentation possible.
Top comments (0)