Chiplet, not so fast, did you look at everything?

In 2005, several colleagues and I began an experiment that would eventually become part of the Pentium D processor programme. The idea was straightforward to describe, but rather less straightforward to execute, place two processor dies in a single LGA775 package.

Pentium D

We did not call them chiplets at the time. We called the concept an MCP, a multi-chip package.

Back then, I was a performance architect, largely focused on countering the seemingly unstoppable rise of the Athlon 64 by extracting every last measure of performance from the architecture we already had. We therefore designed a substrate capable of accommodating the two dies and, to our considerable satisfaction, the first package booted almost immediately. The front-side bus already included a configuration mechanism intended for multiprocessor operation, and the system came to life remarkably smoothly.

We sent the design into validation. The architects were delighted, and the transition appeared almost effortless.

Some of us already knew that Conroe and Merom were due to arrive with considerable impact in 2006. We therefore needed to ensure that the same front-side bus approach could support what would later become the Core 2 Quad. Yes, I know, the naming was not always our finest achievement.

The Intel Core 2 Quad

What we did not anticipate was what happened during extended reliability testing.

A number of Pentium D packages began failing unexpectedly, and surprisingly early in the validation cycle. The puzzling part was that dies from precisely the same performance bins were already operating perfectly well in products being shipped in very large volumes. There appeared to be no obvious reason for them to fail merely because they had been placed together in the same package.

Whenever one of these headaches appeared, I tended to volunteer to investigate, usually by involving myself in matters that were not officially mine.

We examined the failures and eventually discovered that the two dies had been paired according to frequency, but not necessarily according to leakage. That distinction proved to be extremely important, particularly because the affected transistors were the interface devices driving the front-side bus. These I/O structures operated at somewhat higher voltages and were therefore especially sensitive to thermal and electrical imbalance.

Once leakage became an additional binning criterion, the packages began passing the long-duration reliability tests.

At the physical level, the problem was an electrothermal imbalance. The lower-leakage die remained cooler, while the higher-leakage die gradually became warmer. As its temperature increased, its leakage rose further, creating a self-reinforcing effect. Current density became increasingly concentrated in the hotter, leakier structures, accelerating the ageing of the front-side-bus transistors through mechanisms such as electrical overstress and electromigration.

To put it less formally: electrons have an inconvenient habit of gathering along the easiest path of least resistance, and in this case they were effectively conspiring to destroy the interface transistors of the leakier die.

This experience is one reason I look at today’s move towards asymmetric and heterogeneous chiplets with a certain degree of caution.

UCIe PHYs can provide impedance control, equalization and adaptation at the interface. Those features are essential, but they do not, by themselves, solve package-level thermal and leakage imbalance. The complete assembly must still be characterized as a coupled electrical and thermal system not simply as a collection of individually qualified dies.

Balancing leakage across heterogeneous chiplets is considerably more difficult than matching two nominally identical dies. Different process technologies, voltage domains, activity profiles, physical sizes and thermal densities can all contribute to unequal ageing. Temperature gradients sustained high-current activity, local current-density hotspots and electromigration may only reveal themselves after prolonged operation.

Now, you probably understand what I am cooking, enough tools to make sure I don't meet those conditions.

That is why I ultimately abandoned the first version of the mSoC architecture. I could not see a credible route to an acceptable service life without an enormous and costly programme of long-term validation.

Anyone working on disaggregated architectures will eventually have to confront these issues. Chipletisation changes the thermal, electrical and reliability behaviour of the system. A die that is perfectly reliable on its own may behave quite differently once it is placed beside another die with a different leakage profile, workload, power density or thermal path.

It is very important to know if your thermal hot spots will affect your interconnects, as they are the one you need to balance dynamically the most.

This is also why I now concentrate on a chiptile architecture. It is based on a structure whose matching, thermal behaviors and qualification methodology I understand and for which I know how to build a credible path towards reliable high-volume production, without discovering the most unpleasant surprises only after the product has left the laboratory.

Dynamic autonomous design, 2 variations of the same chiptile generated with clicks ...

Just different size of Machine learning acceleration to study that phenomenon with Digital Twins

The post Chiplet, not so fast, did you look at everything? appeared first on LinkedIn.