As chiplet-based architectures reshape the semiconductor landscape, system-level verification has become the single greatest engineering bottleneck. Decomposing a monolithic SoC into multiple heterogeneous dies delivers undeniable benefits — better yield, mixed-node flexibility, and design reuse — but it also forces verification teams to rethink every assumption they once held about how simulation, FPGA prototyping, and post-silicon debug fit together. This article examines how each verification stage must evolve, and how DFT strategies, security verification, and AI-driven EDA tools are filling the gaps that chiplets have exposed.
Why Chiplet Verification Is Fundamentally Different
A monolithic SoC verification flow follows a relatively linear path: RTL simulation confirms functional correctness, emulation and FPGA prototyping accelerate software bring-up, and post-silicon validation catches what pre-silicon methods missed. Chiplets break this linearity.
The Complexity Multiplier
Each chiplet in a multi-die package is an independently designed, independently manufactured piece of silicon. When two or more chiplets — potentially from different vendors, fabricated at different process nodes — must communicate through a die-to-die (D2D) interface such as UCIe (Universal Chiplet Interconnect Express), the verification space undergoes combinatorial explosion. Cross-die timing, coherency protocols, power sequencing, and thermal coupling all become first-order verification concerns rather than corner-case checks.
According to a 2024 study published in the International Journal of Computational and Experimental Science and Engineering, the verification of multi-chiplet AI accelerators “represents one of the most formidable challenges in contemporary semiconductor design,” citing substantial infrastructure costs and debugging cycles that can span days or weeks for distributed simulations.
What Changes at the System Level
In a monolithic flow, the top-level testbench has full visibility into every signal. In a chiplet system, no single entity owns the complete design. Die-level verification environments must be composed — not merged — at the system level. This demands:
- Standardized interface models (UCIe VIP, BoW models) that can bridge independently verified dies
- Distributed simulation architectures where each die runs in its own process, connected via virtual channels
- Explicit system-level coverage models that target cross-die scenarios rather than re-verifying intra-die functionality
Stage 1 — Simulation: The Foundation Under Pressure
RTL Simulation for Individual Dies
Die-level RTL simulation remains the bedrock. Each chiplet must be functionally correct, timing-clean, and well-constrained before it enters any system-level context. UVM-based verification environments with constrained-random stimulus and functional coverage are the standard methodology here. The key difference in a chiplet flow is that each die’s verification environment must be reusable and composable — it will be plugged into a larger distributed testbench later.
Distributed and Co-Simulation for Multi-Die Systems
Simulating the full multi-die system as a single flat netlist is impractical. Memory requirements alone can exceed what even the largest compute clusters provide. The industry has responded with distributed simulation, where each die runs as a separate simulation instance and inter-die communication is modeled through socket-based or shared-memory channels.
Cadence has documented this approach in its white paper on streamlining functional verification for multi-die designs, showing that distributed simulation enables full system-level verification long before interposer characteristics are finalized. Synopsys similarly emphasizes that system-level verification for multi-die architectures requires a combination of hybrid models and traffic generators to focus verification effort on cross-die interactions without re-simulating verified die internals.
Research frameworks such as CHIPSIM and LEGOSim have demonstrated that co-simulation approaches — coordinating computation and communication phases under unified global simulation time — can reduce synchronization overhead by up to 99.9% compared to per-cycle synchronization while maintaining average errors below 4%.
What Simulation Cannot Solve Alone
Even with distributed simulation, pre-silicon methods hit a wall when it comes to:
- Real-time software execution — firmware and OS stacks run orders of magnitude too slowly in RTL simulation
- Analog/mixed-signal interactions — UCIe PHY layers include significant analog content that pure digital simulation cannot capture
- Performance validation — true system throughput and latency can only be approximated in simulation
This is where prototyping takes over.
Stage 2 — FPGA Prototyping: Bridging Pre-Silicon and Real Hardware
The Role of FPGA-Based Prototyping
FPGA-based prototyping has evolved from a “do-it-yourself” construction kit into an essential SoC verification and system validation tool. Running at tens of MHz — compared to Hz-range RTL simulation — prototypes enable software teams to begin development months before silicon arrives.
For chiplet designs, FPGA prototyping serves three critical functions:
- Hardware-aware software enablement — drivers, firmware, and OS bring-up proceed on a cycle-approximate representation of the actual hardware
- System-level performance estimation — real workloads reveal bottlenecks that simulation-based traffic generators miss
- Interface stress testing — D2D links can be exercised under realistic traffic patterns and error injection scenarios
Multi-Die Prototyping Challenges
Mapping a multi-chiplet system onto FPGA boards introduces its own complexity. Each chiplet must be partitioned across one or more FPGAs, and the inter-FPGA links must faithfully represent the D2D interconnect’s bandwidth and latency characteristics. Intel researchers have proposed structured validation platforms that include hardware-aware software enablement, FPGA-based prototyping for seamless hardware porting, and specialized infrastructure for silicon system measurement — validated on a 20-chiplet System-in-Package.
Siemens EDA has noted that as chip designs exploded in complexity and software content increased exponentially, FPGA-based prototype platforms have become “uniquely suited to address those challenges” and are now essential to SoC verification and system validation.
The Handoff from Simulation to Prototyping
The transition is not a clean handoff but an overlap. Simulation and prototyping run concurrently for weeks or months:
- Simulation continues to close functional coverage on corner cases and protocol-level compliance
- Prototyping takes over workload-driven validation, software integration, and performance tuning
- Cross-referencing between the two catches discrepancies — a bug found on the prototype is reproduced in simulation for root-cause analysis
Stage 3 — Post-Silicon Debug: Where Chiplets Hurt the Most
Known Good Die and System-Level Test
Post-silicon validation for chiplets begins even before system assembly. Each die must pass Known Good Die (KGD) testing to ensure that only functional chiplets enter the package. This is a departure from monolithic flows where wafer sort and final test operate on a single piece of silicon.
Once assembled, System-Level Test (SLT) exercises the complete multi-die package under real operating conditions. SLT catches defects that structural test (scan, BIST) and functional test individually miss — particularly defects related to inter-die communication, power delivery network interactions, and thermal-mechanical stress.
The Debug Gap
The biggest pain point in post-silicon chiplet debug is observability. In a monolithic chip, scan chains and debug buses provide reasonable internal visibility. In a multi-die package, the debug infrastructure must span die boundaries. Key questions include:
- How do you trace a transaction that originates on Die A, traverses the interposer, and completes on Die B?
- How do you correlate timestamps across dies that may have independent clock domains?
- How do you inject faults at the D2D interface to reproduce field failures?
The industry is responding with unified cross-chiplet waveform databases and debug tools that can stitch together traces from multiple dies into a coherent system-level view.
Connecting Post-Silicon Back to Pre-Silicon
Post-silicon findings must feed back into the simulation and prototyping environments. When a silicon bug is found:
- The failure signature is captured from SLT or in-system debug
- Engineers reproduce the scenario in the FPGA prototype (fast turnaround) or RTL simulation (full visibility)
- The root cause is identified, and the fix is verified across all three platforms
- Regression suites are updated to prevent recurrence
This closed-loop flow is what separates mature chiplet programs from those that drown in debug cycles.
DFT Strategies for Chiplet Architectures
Why Traditional DFT Falls Short
Design for Test methodologies developed for monolithic chips assume a single test access port, a unified scan chain architecture, and a single set of BIST controllers. Chiplets shatter these assumptions. Each die may come from a different design team — or a different company — with its own DFT infrastructure.
IEEE Standards and UCIe Test Modes
The industry is converging on standards-based approaches. IEEE 1838 defines a die-level wrapper and test access architecture specifically for 3D and 2.5D integrated circuits. UCIe itself includes dedicated test modes that allow structural test of the D2D link — including loopback, PRBS pattern generation, and lane margining.
A robust chiplet DFT strategy includes:
- Die-level wrapper (IEEE 1838) for isolating and testing each chiplet independently
- D2D link test via UCIe sideband and mainband test modes
- System-level BIST that exercises cross-die data paths after package assembly
- Repair and redundancy mechanisms for inter-die interconnects where possible
The Manufacturing Test Flow
The chiplet test flow typically proceeds in stages:
- Wafer-level test — structural and parametric test of each die on the wafer
- KGD screening — only dies that pass move to packaging
- Post-assembly test — D2D link bring-up, loopback verification, and system BIST
- System-level test (SLT) — full application workloads under realistic conditions
- Burn-in and reliability screening — accelerated aging under voltage and temperature stress
Amkor has emphasized that “DFT, automation, and SLT are essential to keep complexity and cost under control” in chiplet-based designs, particularly for automotive and AI applications that require heightened reliability.
Security Verification: A New Frontier for Chiplets
Expanded Attack Surface
Chiplets fundamentally expand the hardware attack surface. In a monolithic chip, all logic resides on a single die within a sealed package. In a chiplet system, D2D interconnects on an interposer or in a package substrate are physically accessible — or at least more accessible than signals buried within a monolithic die.
Identified threat vectors include:
- Hardware Trojans — a malicious chiplet from an untrusted vendor can snoop, modify, or inject data
- Side-channel attacks — timing and power analysis of inter-die traffic can leak cryptographic keys or sensitive data
- Probing attacks — researchers have demonstrated that interposer wire drivers in chiplet systems are easier to probe than internal nodes, and that delay-based sensors are insufficient to protect against laser probing techniques
- Man-in-the-middle attacks — a compromised intermediate die can intercept and alter data flowing between legitimate chiplets
Verification Approaches for Security
ChipletQuake, a framework presented by Semiconductor Engineering, introduces on-chiplet verification of adjacent chiplets’ physical security and integrity during the post-silicon stage. This addresses a critical gap — verifying not just that a chiplet functions correctly, but that it has not been tampered with.
Security verification for chiplets must span:
- Pre-silicon — formal verification of information flow properties, ensuring no unintended data leakage paths exist across die boundaries
- Simulation — fault injection campaigns targeting D2D links to assess resilience against protocol-level attacks
- Post-silicon — runtime monitoring of D2D traffic patterns for anomaly detection, combined with physically unclonable functions (PUFs) for chiplet authentication
Synopsys has noted that “chiplets multiply the number of possible attack vectors, and the more chiplets there are in a design the harder it is to protect a device.”
AI for EDA: Accelerating Chiplet Verification
Where AI Fits in the Verification Flow
The semiconductor industry is increasingly turning to AI and machine learning to manage the verification complexity that chiplets introduce. Key application areas include:
- Intelligent testbench generation — ML models trained on coverage data can generate stimulus that targets uncovered cross-die scenarios more efficiently than constrained-random approaches alone
- Coverage closure prediction — neural networks predict which verification runs are most likely to hit remaining coverage holes, optimizing compute allocation
- Verification planning optimization — AI-driven tools analyze design complexity and historical data to recommend verification strategies and resource allocation
- Bug triaging and root-cause analysis — pattern recognition across simulation logs, prototype traces, and silicon debug data accelerates the feedback loop
AI-Powered EDA in Practice
Synopsys has deployed AI across its EDA stack, describing a “new era of chip design” where AI-powered solutions “accelerate innovation from system architecture through manufacturing.” For verification specifically, AI is being used to predict layout congestion, timing violations, and yield risks before tape-out — reducing re-spins and shortening time-to-market.
The evolving role of AI in verification extends beyond pure speed improvements. As noted in a Semiconductor Engineering roundtable, verification engineers must now consider power, thermal, safety, and security — domains that were historically outside their scope. AI tools help generalist verification engineers navigate these expanded responsibilities by surfacing relevant insights from complex, multi-dimensional data.
Building a Unified Verification Strategy
The Three-Platform Model
Mature chiplet programs operate across three concurrent verification platforms:
| Platform | Speed | Visibility | Primary Use |
|---|---|---|---|
| RTL Simulation | Hz-range | Full signal-level | Functional coverage, protocol compliance, corner cases |
| FPGA Prototyping | MHz-range | Limited (probes) | Software bring-up, performance validation, workload testing |
| Silicon/SLT | GHz (real speed) | Minimal (debug ports) | Manufacturing test, reliability screening, field-condition validation |
How They Connect
The platforms are not sequential stages but overlapping, interconnected phases:
- Simulation feeds verified models and coverage data to prototyping
- Prototyping validates system-level assumptions and feeds test scenarios to SLT
- Post-silicon findings drive regression updates in simulation and prototyping
- AI tools optimize the allocation of effort across all three platforms
What Success Looks Like
A well-executed chiplet verification strategy delivers:
- Die-level confidence through exhaustive UVM-based simulation with full functional coverage
- System-level confidence through distributed simulation, FPGA prototyping, and SLT
- Security assurance through pre-silicon formal methods, simulation-based fault injection, and post-silicon monitoring
- Manufacturability through standards-based DFT (IEEE 1838, UCIe test modes) and automated SLT
- Continuous improvement through AI-driven analytics that close the loop between silicon data and pre-silicon models
Conclusion
The chiplet revolution is not just a packaging innovation — it is a verification paradigm shift. Simulation, prototyping, and post-silicon debug can no longer operate as loosely coupled stages. They must form a tightly integrated, closed-loop verification ecosystem where data flows freely between platforms, DFT infrastructure spans die boundaries, security is verified at every stage, and AI tools optimize the entire process.
For engineering teams navigating this transition, the message is clear: invest in composable verification IP, adopt standards like UCIe and IEEE 1838 early, build security verification into the flow from day one, and leverage AI to manage the complexity that no human team can handle alone. The chiplet era demands nothing less.
发表回复
要发表评论，您必须先登录。