Time To Talk

A topic that surfaced repeatedly at DAC in multiple meetings, on panels, and over morning (and afternoon) coffee was the rapid increase in the size of software engineering teams. There are more software engineers than hardware engineers inside many chip companies these days, and they’re still not addressing an essential problem.

While software teams do an incredible job of ironing out functional bugs in all types of software—and even in fixing problems that show up in hardware after tapeout—they do far too little to improve the energy efficiency of their code. The software engineers say they don’t have the right tools to do that, which is a legitimate point. And the hardware engineers say that isn’t a priority for the software teams, which also is a legitimate point.

It’s hard to throw all software into the same bucket, of course. It’s like saying Asia is a country. There is software to control hardware, there is the OS and middleware plumbing (which includes virtualization), and there are the applications and user interfaces that define a user experience. And deep inside some of these devices there is also embedded code, which performs functions that are sometimes done in hardware when performance isn’t as critical or when it’s simply too late in the design cycle to actually build in hardware.

In most cases, each type of software can be made more efficient. But it can’t be done in a silo, which is the real problem. It’s a running joke that hardware engineers drink coffee or tea and software programmers drink Mountain Dew, and that hardware engineers show up in the morning and software engineers work through the night. The reality is that they’re typically addressing different problems, and as a result power-saving hardware features will continue to be ignored, software will be written without concern for power consumed, and battery life will continue to be shorter than it should be—or in devices with a plug, far more money will be spent on powering and cooling the devices than is necessary.

Simple tools like voltage meters for software teams are a start, but a rather crude one. They’re better than nothing, but not good enough. What’s needed is a methodology for linking the two worlds. As software is written for hardware prototypes, it needs to loop back to everyone involved. The software will have to be changed sometimes, but the hardware might have to be changed sometimes, too. And all of this exchange has to be automated wherever possible because the amount of complexity inside advanced SoCs is becoming unwieldy. At 28nm, understanding the interactions inside an SoC are well beyond the capabilities of the human mind and sometimes beyond the capabilities of even some of the most advanced tools.

The semiconductor industry has solved some of the most complex problems ever encountered in history, but it has never effectively tackled one of its most basic issues—communicating across boundaries. Bringing hardware and software engineers to the same table regularly, establishing a basis for communication, and providing regular updates about the effects of changes on either side to the other is a critical next step. It’s also one of the most daunting. But to make any real future progress, it will have to be done—and done well.

The next big hurdle isn’t about shrinking designs or double patterning. It’s about getting people to work together more effectively. And this may be the hardest challenge of all.