Column: Silicon systems design
Figure 2: Example illustrating how a localised defect or failure within one chiplet can propagate via die-to-die interfaces and become observable only at the system boundary [Source: Keysight]
Timing relationships, protocol
dependencies, power delivery effects and software-driven workloads are often invisible during IP-level verification. These behaviours surface only when chiplets are composed into a complete system, frequently late in the development cycle. As a result, verification success cannot be defined solely by local correctness; it must also account for global interaction.
Emergent failure modes in multi-die systems One of the defining characteristics of system-level verification is the appearance of emergent failure modes. These failures do not originate from a single faulty block but arise from interactions across dies, interfaces and operating conditions. Common examples include:
• Cross-chiplet timing violations triggered by shared clocking or asynchronous boundaries;
• Power and thermal coupling effects that alter behaviour under system workloads;
• Protocol mismatches that remain dormant until specific traffic patterns occur;
• Firmware–hardware interactions that expose corner cases unseen in simulation. In multi-die systems, failures that
appear contained or benign at the component level can surface only when system-level interactions and workloads are exercised. In many cases these issues only appear under realistic workloads or long-running system scenarios. Traditional verification environments, optimised for block-level exhaustiveness, are poorly suited to capturing this class of behaviour.
Limits of block and die-level closure Coverage metrics, assertions and constrained-random testing remain essential instruments for local validation. However, in chiplet-based systems, coverage closure is increasingly decoupled from confidence in overall system behaviour. While coverage metrics indicate which
scenarios have been exercised, they provide limited insight into whether complex system-level interactions behave correctly under realistic workloads. Block-level validation typically assumes that correctness is
compositional: if each part behaves correctly in isolation, the integrated system will behave correctly as a whole. In practice, this assumption breaks down when: • Components make incompatible assumptions about ordering, latency, or error handling;
• Die-level environments abstract away shared power, timing and thermal constraints;
• Validation scenarios fail to reflect realistic software-driven workloads. The result is a widening gap between
verification effort and verification effectiveness. Systems may demonstrate strong local
correctness while still harbouring latent integration defects that emerge only during system bring-up or extended operation.
System-level verification techniques Addressing these challenges requires approaches that operate at the system level rather than treating integration as a final validation step. Key techniques include: • Cross-die protocol verification, focusing on end-to-end behaviour
www.electronicsworld.co.uk February 2026 13
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48
