Column: Silicon systems design
Figure 2: From known-good chiplet to system confi dence
being checked; applying every available verifi cation method to every requirement adds little value.
From known-good chiplet to known-good system T e Open Compute Project’s System in Package Testing work makes a related distinction. It addresses Known-Good- Chiplet testing, package connectivity, inter- chip communication and fi nal functional testing, and notes that some interactions require a system environment. I co-authored that work while at
Tessolve, which is currently listed by OCP as a project lead for its Chiplet/SiP Test workstream. T e engineering implication extends
beyond manufacturing test. A chiplet can be known good against its individual criteria, but an assembled system can still carry integration risks. A “known-good die” is not automatically
a “known-good system”. OCP’s Universal D2D Transaction and
Link Layer specifi cation provides another example of this architectural separation. Version 1.3 supports BoW and UCIe interfaces, separating upper transaction/ link behaviour from the underlying D2D implementation. T at fl exibility makes it more important
to preserve verifi cation intent as behaviour crosses implementation boundaries.
Teams are forced to
confront an uncomfortable reality: the
metrics were not wrong, but they were incomplete
Figure 2 shows an evidence hierarchy from chiplet-level results to system confi dence; it is an engineering framework, not a universal standards-mandated sign-off sequence.
Building the sign-off case No single coverage number proves an AI scale-up fabric is ready. At accelerator level, simulation, assertions, formal methods and coverage can establish local functional intent. At interface level, protocol verifi cation and interoperability testing address boundary behaviour. At package and fabric level, constrained traffi c, fault injection, recovery scenarios
12 November 2026
www.electronicsworld.co.uk
and forward-progress properties exercise interactions. At the hardware/soſt ware level, verifi cation must include the fi rmware and management sequences that confi gure the system, along with workloads that exercise realistic operating conditions. Some interactions will not appear in an isolated RTL testbench. Post-silicon validation and
manufacturing test provide a diff erent kind of evidence. T ey address physical implementation, production test and behaviours that can’t be fully reproduced before silicon is available. T e key is to tie that evidence back to the requirement or risk it is intended to cover. If a limitation remains, it should stay visible in the sign- off record rather than being hidden by an overall coverage result. For AI scale-up systems, the sign-off
question is therefore broader than whether each accelerator has passed its own verifi cation. Engineers also need evidence that traffi c, recovery, confi guration and soſt ware-controlled operation remain correct when the devices work together. As more of the system is built from
chiplets and scale-up links, confi dence will come from showing that this behaviour remains correct across each integration boundary.
T is column continues in next month’s edition of Electronics World
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
