Panelists debate the future of hardware design -

Panelists debate the future of hardware design

San Francisco, CA – No clear winner emerged at the Embedded Systems Conference panel debate on the interdependent futures of hardware and software. Some people believe that hardware design will follow the path of software design, a path from toggling bits to languages of ever-increasing abstraction. This would put traditional hardware designers out of work, replaced by programmers armed with languages that implement circuitry based on an abstract specification. But the hardware proponents argue that too much abstraction makes it difficult for the programmer to truly understand what their systems are doing under the hood, to say nothing of the problems that arise when debugging large, complex software programs. As panelist Larry Mittag put it, “At least when hardware doesn't work, it doesn't work consistently.”

The other panel members were Brian Bailey, chairman of Accellera's high-level language semantics technical committee; Nick Tredennick, editor of Dynamic Silicon and former senior design engineer at Motorola (Dr. Tredennick did the logic design and microcode for Motorola's MC68000 and for IBM's Micro/370 microprocessors); Ed McGettigan, director of systems engineering at Xilinx; Paul Master, vice president of technology at Quiksilver Technology; and Ed Klingman, chairman and CEO of Cybernetic Micro Systems.

The debate's moderator was Jim Turley, an analyst and editor/author specializing in the technology and business of microprocessor chips, embedded technology, and semiconductor intellectual property. He is most widely recognized as the past editor of the Microprocessor Report.

Turley initiated the debate by asking whether the traditional divide between hardware and software is fundamental. “Will the distinction last or can we bridge the gap?” he asked. “Do we even want to?” The panelists established their positions with opening statements.

Larry Mittag, vice president and chief technology officer at Stellcom, an engineering services company for wireless applications, feared that hardware will lose its fundamental firmness as a platform on which to build software. Although generally a proponent of the software camp, Mittag felt it was short-sighted to choose one or the other; whichever gets the job done faster and better is the best choice, he said. Generally, software runs more slowly, but is faster to develop and modify.

Brian Bailey, who was seated on the hardware side of the panel, said, surprisingly, “I have a hard time defending hardware, because that's not what the debate's about. It's about functionality versus all that other stuff. When you design hardware you have to think about implementation. Software just deals with functionality.”

Nick Tredennick put his opinion succinctly. “Productivity trumps consistency, generic trumps custom, and soft trumps hard,” he said. His point was that the efficiency, in terms of design resources, yielded by doing things in software outweighed the potentially greater precision and speed gained by designing hardware in established languages such as Verilog. He went so far as to say, “Microprocessors are a mistake,” to the amusement of the audience and fellow panelists.

Ed McGettigan insisted that software and hardware designers can happily co-exist, citing the cooperation between development groups in his company as proof. Hardware is better suited for some projects, while software is the solution for others.

After brief statements from Paul Master and Ed Klingman, the debate turned to the question of efficiency, an issue which Nick Tredennick touched on in his opening statement.

“The bottom line,” said Mittag, “is when can you get the job done? Can you get the job done in software? You have to optimize the resource that's important. That resource is engineering time.”

“Software might be slower to execute, but faster to develop,” summarized Turley.

“Yes,” said Mittag. “In general, it's quicker to change software than hardware.”

Turley then asked whether that meant hardware design languages would lead to sloppy design, something which is seen more often in software, where flaws are not always as difficult to correct.

Ed McGettigan responded that programmable logic was a palliative for this problem because it made it possible to “hack a design until it works, rather than wait however long for an ASIC.”

In response, Turley floated the idea that if the iterative process for design was the natural one, the one we inevitably revert to, designing hardware with software-like languages only made sense.

Ed Klingman said that this was, to an extent, how people already worked, regardless of whether they were doing so in hardware or software.

“No one gets it right the first time. Hillary Clinton encountered this problem when she tried to redesign 15% of the country's economy. You just keep improving your product,” Klingman said.

When Turley posed the hypothetical situation of designing a well spec'd product and asked the panelists to choose an all-software or all custom-hardware implementation, all of them agreed that they didn't have enough information about the product to make the choice. Bailey pointed out that the budget would affect the decision, since the cost of hardware depends on unit volume. Klingman admitted a personal bias: he would choose to implement the widget in custom hardware. Mittag sheepishly offered that he would work with whichever he was most comfortable with, and “construct an elaborate set of rationalizations justifying that choice.”

These responses embodied the closest thing to a consensus reached at the debate: at present, the superior hardware design methodology depends, like many other design choices, on the individual engineer and the application itself.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.