91³Ô¹ÏÍø

Three Key Challenges for Multi-Die System Verification

Multi-die systems may consist of:

• A 2.5D package containing interposer-mounted chiplets
• A 3D stack with regular structures, such as memory and FPGAs
• Heterogeneous stacks mounted on interposers/bridges
• A recursive composition formulation, which are essentially stacks of stacks in which the system is partitioned to balance throughput and energy

Each of these configurations represents a combination of independently manufactured dies interconnected through communication fabrics, which enable designs with a massive size. There¡¯s also an array of new components to contend with, including bumps, micro-bumps, through-silicon vias (TSVs), interposers, and interconnect bridges. Given the increased scale and complexity, the incremental refinement design flow typical for monolithic SoCs will not work here. After architecture design of monolithic SoCs, teams typically write the RTL and tests, find issues, and possibly change the architecture, going back and forth between these steps as needed. Then it¡¯s time for synthesis, timing analysis, more changes, power estimation, more changes, and so on. These incremental refinement steps continue as the design moves closer to becoming a physical chip. Such a flow isn¡¯t possible with a multi-die system architecture because the dies are already manufactured and all components must be verified from a system-level perspective. Instead, the concept of system-level aggregation needs to be integrated into the flow.

Let¡¯s highlight three key challenges in verifying multi-die systems, along with what¡¯s needed to address them:

1. System verification must validate assumptions made during the architecture design, considering parameters including die-to-die communication, delay, jitter, coherency, power, guaranteed delivery, and errors. By contrast, delay is the only consideration for monolithic SoCs. This challenge with multi-die systems can be eased by adopting standard die-to-die interfaces such as Universal Chiplet Interconnect Express (UCIe) IP along with verification IP.
2. Design size and complexity exacerbate verification. Scalable simulation and emulation models along with a system integration methodology can provide the capacity and performance required.
3. Knowing when verification is complete can be tough to determine. Die-level bugs cannot be fixed at the system level, so exhaustive verification of individual dies with comprehensive functional coverage is necessary. This allows the system-level verification to focus on scenarios using an explicit coverage model that, for example, ensures that data arrives at the right place and with the expected throughput and latency. 

Getting a Head Start with a System-Level Verification Approach

As a best practice, design teams must model, lay out, and verify their multi-die designs in the context of the system. With this approach, many design aspects and optimizations¡ªfrom horizontal and vertical partitioning and placement to die-to-die communication, power, and thermal considerations¡ªbecome architectural decisions. Much of the work must be performed early on, when changes are still feasible in terms of optimizing the design. A framework for end-to-end co-exploration and co-optimization of technologies, architectures, and algorithms can provide a pathway for architectural exploration that allows for quick estimates of PPA for a range of workloads.

When it comes to verifying a multi-die system, however, once each of its individual blocks is designed and verified, and the system is assembled, the system must then be verified as a whole. The flow for this could apply a modularized approach, much like board-level verification.

Multi-die system verification should thus focus on:

• Complex functions spanning multiple dies
• Performance that is a function of multi-die functionality
• Functional scenarios

A basic functional test is to assemble and simulate the RTL of all the dies in the system. How do you approach this when there could be compile issues for simulation (which require you to avoid name clashes) and capacity implications (in which the compute-server may not have enough memory to build and execute the simulation)? Can die-level testbenches be reused and/or synchronized? Can the simulation be distributed over multiple servers?

When assembling the multi-die system for simulation, having a single executable to simulate system aggregation can be an efficient and effective method. However, simply compiling all the dies together will likely trigger name clashes. What if you could analyze each die in a separate library? Based on this approach, the same names (or module) could be used for multiple dies, without name clashes. The system assemblage should require only the top-level assembly and configuration files, requiring no changes to per-die code.