Eye Diagram Debug in Advanced Packaging: What Changes When You Move to Chiplets
Updated: 7 days ago
By Maria Elizabeth Zamudio, Ph.D. | Signal Edge Solutions
There's a moment every packaging SI engineer knows well: the eye diagram looked clean in eye diagram simulation, the package model passed every check, and then silicon bring up shows a closed eye at the exact channel you were confident about. Nothing in the PCB level playbook quite explains these advanced packaging challenges, because the problem isn't on the board. It's living somewhere inside the package.
As chiplet architectures and UCIe based interconnects become the default for high performance ASICs, this is becoming a routine debug scenario rather than an edge case. The eye diagram is still the right tool for signal integrity debugging. What changes is where you have to look, and how you read what it's telling you about package level SI issues.
Why Does Package-Level SI Behave Differently?
On a traditional PCB channel, an eye diagram closing usually points to a short list of usual suspects: trace length mismatch, via stubs, dielectric loss, or connector transitions. Advanced packaging adds several more failure modes that don't exist — or barely exist — at board level:
Bump and micro-bump transitions, where impedance discontinuities are tiny in absolute terms but large relative to the short channel length
Interposer routing density, where crosstalk coupling between adjacent chiplet-to-chiplet lanes is far tighter than anything seen on a PCB
Through-silicon vias (TSVs) and RDL layers, each introducing its own impedance profile that standard PCB stack-up intuition doesn't map cleanly onto
Die-side ESD and driver loading, which interacts with the package channel in ways that are easy to under-model if the package and die teams are working from separate tools
Worth flagging up front: for UCIe-class interconnects, which typically run under 20 mm, TDR isn't a check called out in the UCIe standards themselves, and it's more commonly associated with high-speed SerDes links such as 224G. At that trace length, impedance mismatch is rarely the dominant failure mode, crosstalk and uneven current sharing across the interconnect tend to matter more. TDR still earns its place in the workflow below as a localization tool once a discontinuity is suspected, but it's a diagnostic step, not a UCIe compliance check.
The result is that a channel can pass every rule-of-thumb check that would clear it on a board, and still show measurable eye closure once you're working at UCIe-class data rates over interposer or RDL routing. This makes eye diagram simulation necessary for verifying signal pathways in chiplet architectures.
A Practical Debug Sequence
When an eye diagram shows unexpected closure in an advanced package channel, the fastest path to root cause is usually to isolate the problem geographically before touching any parameters. A workflow that holds up well in practice for these advanced packaging challenges:
Split the channel into segments — die-side routing, bump/micro-bump transition, interposer or RDL routing, and the transition back to die on the receive side. Simulate each in isolation against its own reference impedance.
Compare TDR response at each transition point. Bump transitions in particular tend to show up as short, sharp discontinuities that are easy to miss if you're only looking at the full-channel insertion loss plot.
Check adjacent-lane activity before blaming the victim channel. Interposer routing density means crosstalk is often the real driver of eye closure, even when the aggressor lane looks unremarkable on its own.
Re-run the eye with die-side loading from the actual driver model, not a generic termination. Package channels are short enough that driver behavior has outsized influence compared to board-level channels.
In most cases, this sequence narrows a “mystery” eye closure down to one of two things: a bump-transition discontinuity that wasn't captured at the resolution the package tool defaults to, or crosstalk from a neighboring lane that wasn't in the original simulation scope.
What is a TDR Response at the Discontinuity?
A TDR sweep across the channel makes the transition easy to spot directly: a flat trace at the reference impedance, then a localized bump right where the bump/via geometry sits, then a return to the reference level.

Because these transitions are physically tiny, seeing them clearly requires enough bandwidth in the EM extraction, often 50 GHz or more, to resolve the discontinuity rather than average it out. TDR time-step resolution should scale with that bandwidth: coarser sampling will smear a sub-millimeter bump transition into the surrounding trace and mask it entirely. For a deeper look at TDR fundamentals and resolution trade-offs, see our blog on the subject.
Illustrating the Eye
A simple way to visualize this is a channel with a single localized impedance discontinuity, such as a narrow bump-transition segment sitting between two 50-ohm sections. Even a small mismatch there is enough to measurably narrow the eye opening, which can be analyzed using eye diagram simulation compared to a clean, uniform channel:

The Takeaway for Design Teams
The instinct to treat package level SI as "PCB SI, just smaller" is understandable, yet it's also the fastest way to miss the actual root cause of package level SI issues. The physics scales down, but the relative significance of each bump transition discontinuity scales up; a transition that would be noise on a board can be the dominant term in a package channel.
Catching this at the simulation stage, before tape out, is dramatically cheaper than catching it at bring-up. That means package level eye diagram simulation needs the same rigor as board-level SI — segmented channel review, transition-by-transition TDR response analysis, and crosstalk analysis that accounts for interposer routing density — built into the design flow from the start, not added after silicon comes back looking wrong.
Have a package level SI challenge that isn't behaving the way board level intuition suggests? Get in touch — this is exactly the kind of problem our team works through daily.



Comments