Chiplets: move the boundary, then solve the system

Partition by system value

Chiplets allow a system to be assembled from multiple dies. This can support reuse, process-node choices and designs that would be difficult to realise as one monolithic die. It also creates interfaces that were previously internal to the silicon. Those interfaces consume area, energy, latency and engineering effort.

The useful question is therefore not whether chiplets are modern or whether a smaller die has better yield. It is whether a particular partition improves the complete product. A compute tile, an I/O die and a memory stack can have different process and physical needs. Separating them may be sensible, provided the data exchange between them remains affordable.

I would begin with the workload and communication graph. Which blocks exchange data most frequently? Which connections require low latency or predictable service? Which functions can be reused across product variants? A boundary that looks clean in an organisation chart may be expensive in bandwidth.

Account for the cost of crossing a die

A die-to-die connection needs a physical implementation and a communication protocol. The package determines practical routing, bump placement and signal behaviour. Link training, error detection, retry, management and test access add further requirements. An industry standard can improve interoperability, but it does not select the product architecture or eliminate integration work.

UCIe provides a framework for die-to-die connectivity. The system designer still needs to choose supported capabilities, verify interoperability and define how the link interacts with the rest of the platform. A memory transaction can encounter queues and arbitration beyond the physical interface, so link latency alone is not an end-to-end guarantee.

Model yield at the package level

Smaller dies can improve the random-defect component of manufacturing yield, but the complete cost comparison must include more than wafer yield. Additional interfaces occupy silicon. Packaging can become more complex. Test requirements expand. Assembly has its own losses. A failed package can consume several otherwise good dies.

A simple illustrative calculation makes the accumulation visible. If four required dies each have an independent 99% probability of meeting a defined incoming quality criterion, the probability that all four meet it is about 96.1% before assembly effects. This is an arithmetic model, not a prediction of manufacturing yield. Real test escapes, correlations and repair options require a more detailed treatment.

Known-good-die strategies, built-in test and package-level observability therefore belong in the architecture discussion. Testing only the finished assembly may make diagnosis expensive and scrap unnecessarily valuable components. Testing each die is also not sufficient to reveal every failure introduced by the assembled system.

Include product mix in the model. Reusing one compute tile across several products can spread development effort, while a specialised tile may reduce efficiency in a different workload. Reuse creates value when the variants actually share requirements.

Bring physical and operational teams in early

Thermal behaviour can invalidate an otherwise attractive partition. Stacking shortens some connections but changes heat removal. Side-by-side dies may simplify cooling while requiring a larger package. Power delivery, mechanical stress and package routing impose constraints that cannot be resolved by protocol choices alone.

The operating model also changes. A multi-supplier package needs agreement on test data, failure analysis, change control, traceability and responsibility for customer failures. A component can meet its individual specification while interacting badly with another component. Someone must own the assembled product’s acceptance criteria.

For an early feasibility review, I would compare a monolithic baseline with a small set of candidate partitions. Each option should carry an estimated bandwidth budget, latency path, thermal envelope, test strategy, cost model and integration risk. The comparison should include software and validation effort alongside silicon and package costs.

Chiplets are a powerful architectural option when the partition matches the workload and the product family. Their strongest promise is flexibility across technology and reuse. Realising that promise requires the same discipline as any complex system: clear interfaces, complete budgets, observable behaviour and one accountable integration plan.

Further reading

• UCIe Consortium — Interface, test and integration questions
• UCIe Consortium — Specifications and ecosystem