Performance Or Power?

There’s a reason why Microsoft is buying part of Nokia and why Apple is developing its own chips. But there’s still a big problem to solve.


For high-volume chips, such as those slated for mobile devices such as tablets or smart phones, energy efficiency is absolutely critical. For very high-value chips, which are the ones that show up in PCs or servers, the focus is more on performance and how efficiently that performance is obtained. And for the stuff in the middle, notably the Internet of things, the commodity servers and automotive and industrial applications, the focus is generally one or the other.

This should be a balancing act. But due to lack of communication across teams, the equation is remarkably lopsided. That’s a problem, because failure to optimize the software that runs on the hardware can bring the most powerful chips to a crawl. It can drain batteries in a fraction of the time that they’re supposed to last, and it can cost millions of dollars inside of data centers each year for powering servers and cooling them to within acceptable limits.

While corporations have spent many millions of dollars on improving server utilization, they have spent comparatively little time addressing the software that runs on them. And while consumers wait in long lines for the latest smart phones, they give almost no thought to the applications that suck down battery life in just a few hours.

Most engineering teams look at this in black and white. Software is part of a vast ecosystem. Done right, it can significantly improve performance and extend battery life. Done wrong, it can adversely affect both. And engineered the way it usually is done these days, it can prolong battery life or improve performance. But it’s usually an either/or decision, and that’s a problem. What’s needed in this equation is more granularity.

This is a non-trivial engineering challenge, of course. For one thing, the sheer complexity of devices—more functions, more cores, more power domains, more modes of operation and more use cases—makes it extremely difficult to understand all of the possible tradeoffs early on. By the time engineering teams get to tapeout, they’re usually so exhausted that just getting the first rev of the chip to work is sufficient. The power and performance can always be tweaked in the next rev.

New materials don’t simplify the equation, either. The thinking at equipment makers and foundries these days is that materials will have to change significantly at advanced nodes. From a hardware standpoint, that raises all sorts of challenges in terms of variability, power and performance. It even raises issues about getting working chips out the door on time, which also affects cost—the third part of the PPA equation (although in this case the area is replaced by overall development cost rather than just the cost of the silicon).

What’s unfolding here, and what will continue to unfold as we move forward from one process geometry to the next, is that power, performance and cost are becoming increasingly difficult to manage individually. But they’re going to become even more difficult to manage together. In fact, if there is any hope of really optimizing for power and performance, it will have to be done much sooner than later—with an eye toward really improving the way software is created in relation to hardware.

This is a ticking time bomb, and one that requires an industry solution rather than just a lot of little tweaks. There is a good reason why Apple started developing its own chips and why Microsoft just acquired a portion of Nokia. They’ve already made their move. The question is what the rest of the semiconductor industry will do in response.

—Ed Sperling