Chiplet architectures aimed to improve the economics of large die silicon. Splitting a monolithic SoC into smaller tiles lets teams pair compute and memory density with suitable process nodes, while limiting the yield exposure of a full-die failure. The financial case holds. Verification effort is less straightforward.
Moving from a single-die SoC to a multi-die chiplet assembly does not simply double or triple the verification workload. It grows closer to the square of the die-interface count, since cross-die interactions expand combinatorially. A team sized for one die often sees the problem only at the worst time, three months before tapeout.
How Multi-Die Verification Changes
With one die, the verification environment exercises the RTL directly. Signals, buses, and protocols share one simulation domain, while coverage models describe state changes through the design's internal signals. In a multi-die design, the physical die boundary becomes an architectural boundary, and the RTL treats that connection differently from an internal path.
UCIe (Universal Chiplet Interconnect Express) and other die-to-die protocols add an abstraction layer. RTL-level simulation does not accurately represent the serialized physical interface at timing level, so verification operates above the physical layer at the protocol level. That is manageable. UVM agents for UCIe and MIPI D-PHY exist. The harder issue is that protocol abstraction creates transaction boundaries that the testbench must cover explicitly. Those boundaries also intersect with module-level coverage in ways that are easy to miss.
Several recurring categories account for multi-die coverage holes.
Die Link Handshakes
A UCIe link uses defined credit-based flow control. Each die tracks outbound credits, and the receiver returns them after consuming transactions. In ordinary traffic, credits remain available and transactions proceed. The useful stress cases are credit starvation, credit underflow detection, and recovery after link-level errors.
Most chiplet verification environments exercise the link separately under clean conditions, then expect system-level tests to combine the stress cases. That rarely happens. The system testbench works at a higher abstraction, while link stress requires exact injection at the protocol transaction layer.
Cross-die coverage commonly leaves these arcs open: returning credits while injecting a new transaction, starvation during asymmetric traffic, and link-level retry inside an active multi-packet transaction. None is unusual under load. The testbench simply was not designed to inject them directly.
Reset and Power Across Dies
Single-die designs may contain complicated reset trees, but their reset boundaries remain internal and can be exercised through coordinated reset injection in a UVM test. Multi-die systems add sequencing dependencies across physical boundaries. When the compute die asserts reset, the memory die controller must drain transaction buffers before the interface is released. If that memory die uses an independently power-gated domain, reset behavior also depends on the power state when reset is asserted.
This scenario generates some of the most inventive post-silicon bug reports. The failure may be a race that appears only with a particular power state and load combination, conditions the validation team never injected. The coverage model often omits cross-die power state because the testbench drives each die separately instead of representing their combined state.
The remedy is structural rather than merely additive. Build a cross-die coverage model for the joint states: die A power state, die B power state, and outstanding transactions on their interface. That exposes the unhit arcs. Without the model, there is no way to tell whether those corners ran.
Cross-Team Testbench Ownership
When separate teams own separate dies, the coverage issue also becomes organizational. The compute die team covers its interfaces in isolation, and the memory die team does the same. The cross-die functional coverage model has no clear owner.
This is a structural result of chiplet project organization, not simply a communication problem. The cross-die interface belongs to a specification, not to one team. Verification plans cite that specification, but coverage code resides in separate team testbenches, and neither team can see the other's coverage database.
A workable pattern is to assign a verification integration owner for the die-to-die coverage model and system-level testbench. That owner does not replace either die's testbench. The role is to model joint behaviors absent from both environments and run those tests against both die RTL models in one simulation. Teams often resist the added headcount. The alternative is discovering cross-die bugs after silicon.
Chiplet-Specific Automation Paths
Automated stimulus generation has greater value in chiplet verification than in single-die work because cross-die stimulus is difficult to explore manually. A directed test for UCIe credit starvation must coordinate transaction injection across two independent UVM agent classes, with cycle-level timing precise enough to reach the starvation window.
That stimulus pattern is well suited to generation from a coverage specification. Identify the target arc, and the generator finds coordinated transaction sequences across both agents that can reach it. The resulting test closes the hole without requiring a verification engineer to spend a week writing a directed test.
Internal pilot data from 3 early-access teams working on chiplet or multi-die designs showed that cross-die handshake and power sequencing arcs had the highest ratio of "hard to write by hand" to "reachable by automated generation." Automation does not remove the need for structural testbench investment. The joint coverage model and integration environment remain necessary. Once they exist, generation is tractable, even though single-die designs have a narrower stimulus space.
When You Are Late
Many teams find cross-die coverage holes three to four weeks before tapeout, when system-level regressions begin and the coverage database exposes interface-level covergroup gaps that received little review. The decision is practical, not theoretical: which gaps create enough respin risk to justify the remaining schedule, and which can be waived?
A waiver is defensible only with a clear risk statement: the arc represents condition X, condition Y would be required for silicon failure, and Y does not occur in the target use case because of Z. "We ran out of time" is not a risk argument. It is a schedule concession that will resurface during post-silicon failure review.
Build the cross-die coverage model during verification planning, not after the first system-level regression. Chiplet architectures are still new enough that many teams are doing this for the first time, and the first design's lessons often arrive after tapeout.