Technology Reboot Required

It’s time to recognize that software is badly written, inefficient, and delaying the move to better hardware architectures.


The International Technology Roadmap for Semiconductors (ITRS) has produced reports outlining the major obstacles the electronics industry faces for a long time now. It attempts to project, with a 15-year horizon, the problems that need to be solved in order to take advantage of the complete design and manufacturing ecosystem. From this, early research efforts can be started. This enabled the EDA industry to see the technology roadmap that semiconductor companies believed they would need in the near future. In more recent times, close cooperation of semiconductor, EDA and IP companies have made this a little less important than in the past. Today, no one can do it all on their own and the entire food chain is brought in to help solve the problems associated with upcoming nodes.

But it is not just technology that is driving the directions that we go in, but the end products, as well. We have migrated beyond the computer being the principal driver to a world where it is supported by a host of other needs, by mobile connectivity and the myriad of connected devices that will soon make up the Internet of Things. With many companies currently indicating they have no need or desire to move beyond 28nm, and in reality the vast majority of the industry is still using much older nodes than this, the latest process nodes are only driving a few companies and a few market segments.

The ITRS recognized these fundamental changes in 2012 and reorganized itself to better address the changing drivers. That reorganization was completed in 2014 and they now call themselves ITRS 2.0.

A few months ago, I published an article titled the “Electronics Butterfly Effect.” Little did I know at the time that an IEEE initiative was looking into many of the same questions and outlining similar directions to those that I talked about in that series of articles. Called the Rebooting Computing Initiative (RC), it is looking at ways in which computer performance can be restored to its historic exponential growth path.

There is a lot of synergy between RC and the new ITRS 2.0 directions and RC. Arvind Kumar, a member of the RC committee, who also has a day job at the IBM T.J Watson Research Center, said “we have formed a partnership with ITRS 2.0 to jointly develop a roadmap of the future and specifically to reach out to industry.” They are setting a 10-year horizon but admit that they are taking a holistic perspective and looking at a wide range of changes.

“We have a number of events planned for this year,” says Kumar. “They include a Birds-of-Feather session at Supercomputing 2015, the RCS-4 Summit in Washington, D.C., after the IEDM, and publication of a special issue of IEEE Transactions on Computers with articles on ideas of how to reboot computing.”

I hope they take a serious look at the software side of the equation, as well as looking at how hardware architectures can advance. Software has become highly wasteful. Much of the time and effort spent on hardware architectural design is doing nothing more than attempting to maintain a consistent environment for software, helping them achieve some kind of efficiency within their process.

The fact that software productivity increases have been less than those of hardware suggest to me that many of the problems are in the software, and it is about time we stopped pandering to their needs. As an industry we need to get them back to reality where their actions are directly correlated to the additional hardware costs they incur, the power they consume, and the environmental impact they have related to the additional power stations necessary to support their wasteful habits.

Once software has been put on a more sustainable course, then new hardware architectures can again be created that will significantly enhance overall compute capabilities at a fraction of the cost of those being designed today. In the early days, supporting software appeared to be a logical choice and didn’t mean significantly raised costs. Today, those costs may be ready to break the camel’s back.

  • My son, a recent Berkeley graduate in Computer Science, is working at large enterprise software company that everyone has heard of. He told me their code base has over 1,000 developers! The first time he tried to check-in his code changes, it took two days. I can’t imagine how to efficiently manage all the interactions 1,000 developers could have on a huge jiggling jello pile of software. Maybe software has to become more like hardware design.