For years, multichip-module technology languished, receiving lots of R&D dollars but never really breaking out of the mil-aero microwave ghetto. Then, quite suddenly, the stacked package was not only here, it was ubiquitous and it was yesterday's news.

The driver for this change was, of course, the cell phone handset. The extreme real estate shortage in the handset dictated increased integration. But the price point for the devices-as close to zero as you or your competitor can get-forbade the kind of over-the-top integration that had, during the bubble, been characteristic of system-on-chip (SoC) designs. Economy dictated that bulk memory, RF and logic would stay on their own dice, where they could be delivered at commodity costs.

The architecture of the handset also helped dictate the stacked-package solution. Despite all of the pressures on cost, performance and energy efficiency, the handset has remained a very conventional, CPU-centric architecture. In response to application pressures, it has simply sprouted application accelerators, all of which could be absorbed into the system SoC with little increase in die size and, hence, little increased cost.

The stacked package was the ideal implementation of this architecture. It uses stock dice with no changes to the pad ring, so the dice can still be had at commodity prices. It requires no repartitioning or rethinking of the architecture. And despite all those years of R&D that went into better ways to connect dice, it uses nothing more sophisticated than multilevel wire bonding.

Because of the huge volume at stake, stacked packages have become cheap, reliable and available. For CPU-centric designs that include bulk memory and perhaps an analog or RF die, they have become an easy alternative to an expensive, risky SoC, and a tool for delaying the migration to really nasty process nodes.

But what about the rest of SoC designs-the ones that don't fit easily into the CPU-centric model, or don't partition into a set of off-the-shelf dice? Must these designs force the design team into 90 nanometers just to achieve lower footprint and lower energy consumption?

Toward transparency
On paper, the answer is no. Several organizations are pursuing die interconnect technologies that can make multidice designs transparent to the architect by vastly increasing the number of connections available between dice and, at the same time, slashing interdie delays to near the delay of a long on-die net.

The most elaborate example would be the work going forward at IMEC. The researchers in Leuven, Belgium, are using through-die vias, around-the-edge interconnect and bump layers on both faces of the die to build stacks of dice with interconnect sites all through the stack. Combined with special I/O pads that are scaled to the actual impedance of these interdie links, this approach promises to almost eliminate the distinction between on-die and off-die to the architect, synthesis engineer or timing/signal-integrity expert.

Another, potentially far simpler approach doesn't rely on any new process steps at all. SiliconPipe, a San Jose, Calif., startup, has developed an approach using strip-line interconnect techniques-borrowed from those microwave module engineers-to create multigigabit/second nonencoded links between chips at the board level. Applied to the world of multidice packages, these techniques could eliminate most of the need to explicitly partition a design for multidice implementation.

The implications for using commodity parts, avoiding process migration and still getting very high levels of integration are extremely interesting.

Ron Wilson is semiconductor editor for EE Times. Feedback and suggestions are always welcome at rwilson@cmp.com.