EDN Executive Editor Ron Wilson explores how IC design teams really work: the struggle for power efficiency and performance, wrestling with semiconductor processes and design methodologies, the challenges of global design teams. How do we somehow herd architecture, IP, design and verification into a successful tape-out?
Aug 26 2008 11:58AM | Permalink | Email this | Comments (9) |
Blog This! using: Blogger.com | LiveJournal |
Digg This | Slashdot This | add to Del.icio.us
You might imagine that somewhere in a back room at conferences the old hands at microprocessor architecture get together over dinner and a few bottles of wine--the sort that must be concealed in expense reports--lean back in their chairs, and talk long into the night about lessons learned and lessons repeated. Last night the minority of Hot Chips attendees who stayed around after dinner had the privilege of listening in on just such a discussion, staged as a panel.
And an august group is it was. Chaired by Nick Tredennick, who has been in microprocessor design since the Motorola 68000 development, the panel included Insight 64 analyst Nathan Brookwood, Intel vice president and low-power processor pioneer Dave Ditzel, Techvision principal and MIPS pioneer John Mashey, the legendary Berkeley professor and RISC champion David Patterson, former Intergraph guru Howard Sachs of Telarity, and Microprocessor Report founder Michael Slater. As Tredennick said in his opening remarks, "these men need no introduction—if you don't recognize them, just ask your parents."
Setting the tone, Tredennick characterized the industry has having been "fooled by randomness." Architecture is not a science, he argued, because it has only self-validation. "An architect creates a new architecture, and then we let him tell us about all its advantages and conceal all its problems. It's like trying to form an opinion of kids by asking their parents. We should be asking the neighbors."
The tone of the panel remained similarly light. But inevitably, when people of this caliber get together, some profound thoughts precipitated out of the levity. And given the diversity of experience on the panel, their observations were remarkably consistent. Taken together, they could almost form a little handbook of how to, and not to, do a CPU architecture.
Perhaps the first point on which many of the panelists remarked was the inverse correlation--or perhaps, after anti-x86 bias is removed, lack of correlation--between architectural elegance and market success in the processor world. (Given their backgrounds, the panelists focused on the PC and server processing world, not the embedded space.) Hardly anyone would consider the x86 instruction set architecture to be pleasant, let alone elegant, but it has utterly dominated the market. In fact one of the lessons many of the panelists cited was a simple truth: don't go up against x86.
Another key point was the persistence of software. Noting that C, now an ancient language, had defeated all attempts to supplant it, and that some applications still used FORTRAN, Mashey observed "Chips come and go, but software is forever." To apply this aphorism, he pointed out that a new instruction set architecture requires someone to write new operating software, and that is extremely hard and slow. "A really cool chip can mean there is no software for it," Mashey said. Special mention in the category of creating an impossible software problem was reserved for IBM's Cell processor, which, Ditzel pointed out, has not one but two proprietary instruction sets on one chip.
Another point made by the panelists is that, on the whole, the pursuit of instruction-level parallelism had proved frustrating. Nearly a decade ago academic researchers warned that the best average number of instructions per clock on a broad mix of codes might be below 4, no matter how clever the compiler technology. Ignoring this, CPU architects pushed for ever more aggressive hardware, including wide instruction buffers, out-of-order execution, branch prediction, and even speculative execution, to make the machines capable of executing more and more instructions in parallel. The ultimate expression of this trend was the long infatuation in some circles with VLIW (very long instruction word) machines, in which the compiler bore almost all the responsibility for recognizing and preparing instructions for parallel execution, and parallel execution pipe numbers reached toward a dozen. But in the end, the academics proved to have been correct. "I think we have to call VLIW and superscalar approaches near misses," Patterson said.
In contrast, Patterson pointed out—and others agreed—that one concept that had caught on was SIMD (single-instruction, multiple-data) instructions for exploiting parallelism that lies in the data, rather than in the instruction stream. Ditzel even suggested that vector processors, an elaboration on the SIMD concept, might see a resurgence of interest as architects struggle to exploit data parallelism while minimizing energy consumption.
The question of power—whether power density for thermal reasons or total energy consumption for battery-life reasons—also marked a number of comments during the discussion. Ditzel perhaps put it most succinctly: "The quest for low power is driving a return to simplicity in processor architecture." He pointed out, for example, that the just-announced Intel Larrabee processor uses a simple, short execution pipeline based on a 1992 Pentium design—for power reasons.
Other panelists added to this point. Patterson cited superpipelining, in which some architects claimed performance advantages for pipelines as long as 50 stages, as one of the conspicuous failures in the search for performance. He observed that lately, pipelines have been getting shorter, not longer. Brookwood said "performance/Watt considerations will bring us back to using simple, in-order execution pipelines. We just can't afford the power necessary to run all that extra hardware to manage out-of-order execution, and to speculatively execute instructions that we will subsequently throw away."
Instead, the panelists saw a return to simplicity throughout the architectural world. The old debate between architects who relied on complexity to execute ever more instructions per clock and those who relied on simplicity to increase clock frequency seems to have finally been resolved, in favor of simplicity. In the future, it was suggested, we will use our growing transistor budgets to build lots of fast, simple machines with aggressive, smart power management, rather than to build highly complex machines. Moore's Law, which in the past conquered bipolar ECL, GaAs, and SiGe, appears to have slain architectural complexity as well.
Related entries in: Microprocessors | SOC (System on a chip) |