Multicore chips are one piece of the solution to creating chips at advanced process nodes, but they aren’t the whole solution.

Don’t take my word for it. The powers that be—very large chip makers with big development budgets—are fretting over the future of multicore programming. The question being whispered is, ‘If it doesn’t work, what then?’

That’s a many-billion-dollar ‘if,’ and the answer to that question will almost certainly be painful to some engineers. But to date, the number of productivity and corporate-specific applications that truly benefit from having more than one core rather than a faster single core is slim, and the number that can take advantage of four cores is even slimmer. From there the number falls off a sheer cliff, with databases and search applications being the biggest exceptions.

To make up for that programming limitation, some very smart people are thinking about how to rearrange things inside the box. Multicore provided a one or two node bridge, but unless something miraculous happens—and many people are pessimistic about that after four decades—the next big steps forward will be based on materials science.

We’ve been hearing for several years that bulk CMOS is running out of steam. At the front end of the Moore’s Law road map, strained silicon has provided a bridge to yet another node. SOI will likely add a couple more bridges, after which the FinFET model—a new Field Effect Transistor structure with fins—will take over, based on an SOI substrate.

FinFETs and Intel’s Tri-gate model do roughly the same thing. Both use vertically stacked gates, which allow more space for electrons to move. Gates All Around FETs surround the channel with gates, offering yet another approach. All of these solutions reduce current leakage, which means even lower power and less heat. Because heat was the reason behind the addition of so many cores in the first place, don’t be surprised if someone starts cranking up the clock speeds again for a standard number of cores.

It’s important to note, however, that there is no shame in limiting the number of cores on a chip. It’s always good to experiment with new technologies. Failure often forces innovation and leads to the development of new ideas. Looking back over the past four decades of chip development, most of the advancements in chip design were made one painful node at a time. Remember the 1 micron wall?

Like it or not, governments are going to be dictating energy policies in the very near future.

The scenario will start unfolding at the data center, make its way down to the device level, and ultimately land at the system level. At the chip design level, the situation will be particularly bad. For one thing, communication from the top never makes its way all the way down the food chain without an escalation in hysteria at each level. Companies are always afraid of telling their customers that they can’t meet their goals, so they simply pass along the message with a growing urgency to their suppliers.

The problem at the very top is that there are an estimated 1 million servers going online each year in the United States, according to The Uptime Institute, an independent research organization. That number of servers requires the construction of additional power plants, and it’s happening at a time when it’s difficult to get approval for any new plant construction. The situation is particularly bad in China, where power is being rationed in almost all major business centers. Adding more servers to the mix is not likely to be a welcome change, and concern over global warming makes additional power from anything but renewable sources highly unlikely.

From governments to power companies and so on down the line, you can expect lots of finger pointing. The companies buying servers and building new datacenters will demand more efficient machines, and the server makers will demand more efficient components to drive the servers. Software makers will point fingers at the hardware makers, saying they can’t build applications to take advantage of the multiple cores. Hardware makers will point fingers at the applications developers, complaining about bloated applications, operating systems and middleware.

Finally, everything will make its way down to the chip developers, who will be held accountable for fixing the whole problem. Somebody has to be blamed, and they’re the supplier of the supplier to the supplier of the customer. Blame flows downhill. It’s axiomatic, and it should be one of the first things they teach in business schools.

It doesn’t matter that the problems are caused at every level and that the system-level companies have done more than everyone else to fix it. In many respects, the blame should be shared by the end user. But figuring out who to blame may be less important than trying to get ahead of this problem. It’s always worse when the government gets involved in a problem first.

Getting people to change tools or developing environments is like pulling teeth out of a sleeping crocodile. It’s difficult in the best of circumstances, and dangerous at worst.

The problem seems to be one of stubborn attachment coupled with an investment in training that most companies are unwilling to write off. We’ve seen this problem before, and it’s tough to make it go away.

Going back in history, it’s the same reason we’re stuck with a QWERTY keyboard.

The idea behind QWERTY dates back to the 1880s, when typewriter keys used to jam because typists were faster than the machinery. Rather than invent a faster typewriter—something that did happen 70 years later with the IBM Selectric—typewriter makers decided to slow down the typists. Why else would you ever think of putting an ‘S’ under the weakest finger in both hands. The goal was to reduce typing speed by about 20 percent, but once typing teachers had learned the QWERTY keyboard they refused to change. More than 130 years later, we’re still stuck with it.

The same is true of some of the proprietary tools being used by chip developers. While they filled in gaps of commercially available tools when they were first developed, many of them are outdated, klugy or just plain inefficient. The problem is that one group of engineers teaches the next group, and so on. And eventually, no matter how outdated those tools may be, it’s tough to change them out. And if it’s engineering managers who invested time into learning them, they’re far less likely to see the benefits of swapping out what they know in favor of what they don’t know.

In some cases, these tools were developed because the market was too narrow for EDA vendors to make a profit. But tools need to be rethought and re-invented regularly, and budgets for tool development were one of the first things that companies cut, particularly if they weren’t competitive differentiators.

Some EDA tools do offer a competitive advantage. Big companies like IBM and Intel have always developed their own tools for very specific purposes as part of their flows. IBM claims its internally developed tools allow it to get first-time success 95 percent of the time. Intel, likewise, uses its tools to hone its development process and achieve better yields.

Other tools are simply bridges, or they work with outdated processes on older process nodes. And in the worst of all worlds, they work completely in isolation rather than in conjunction with other tools that recognize system-level design needs.

What do you think?