Experienced EDA entrepreneur Jim Hogan has been attending DATE (Design Automation and Test Europe, the European version of DAC) this week in Grenoble and he’s written an account and analysis of an IP panel at the event. (Cadence CMO John Bruggeman was one of the panelists.) Hogan has EDA permeating every cell in his body, I think, from his long association with chip design and manufacturing and his experience in financing successful EDA startups. Hogan’s article in EE Times titled “DATE 2011: SoC Realization, the elephant in the room” effectively captures the current situation in SoC Realization. As Hogan writes:
“IP, and more generally design reuse, is the crux of SoC’s future and value proposition. Everyone agrees that the ability to quickly and efficiently re-use silicon-proven functionality in new designs holds the key to addressing the technical complexity, time pressures and jaw-dropping economics of bringing new SoCs to market. There simply is no other way.”
And that is the truth of the matter. It is inconceivable that we can continue to push chip complexity and not fully adopt IP as the mainstream way to incorporate large, proven, complex functional blocks into our designs. There simply is no other way. No one can afford to reinvent the wheel each and every time. That’s not real engineering. There’s no leverage in any other direction than that of heavy IP use.
To me, the situation is remarkably similar to the state of digital design at the beginning of the 1970s—although the following will probably cause many readers to snort at the orders-of-magnitude difference in the design problems, I can assure you that the problems are qualitatively the same even if separated by 40 years of electronic progress.
Prior to the 1970s, if you wanted to build logic gates, you usually designed them yourself with discrete transistors, resistors, and the occasional capacitor. During the 1960s, the first families of logic ICs with a few gates on a chip started to appear. Sylvania introduced the SUHL (Sylvania Universal High-Level) logic family of TTL devices in 1963. TI introduced the 7400 series of TTL chips in 1964. Motorola was offering RTL, DTL, TTL, and ECL logic families by the late 1960s. But there was a problem with these early logic families. Every semiconductor company created its own set of logic ICs with mutually incompatible logic levels and pinouts. You chose one vendor for each small logic function and hoped that the part wouldn’t go out of production prematurely. It was a bad situation and restricted digital design from achieving its potential.
Finally, the TI 5400/7400 series of digital ICs won out. It was a family that started with a large number of parts and the catalog grew for about three decades. Many other semiconductor vendors jumped on the bandwagon and produced parts that were pin-compatible with TI’s 7400 series logic family. Some added their own special functions to the growing catalog, which further propelled the 7400 family to dominance. As a result of the banquet of choices, digital design flourished and the design community started to ratchet board-level design complexity. Small- and medium-scale circuits gave way to large-scale devices including microprocessors, DMA controllers, graphics chips, UARTs (and DUARTs and QUARTs), and Ethernet controllers. Board-level design complexity really started to soar—because it could.
We are in precisely the same position today with chip design that we were with board design in 1970. Our SoC component choices are limiting our ability to produce complex designs. You need only look at the ITRS complexity-versus-cost roadmaps to see that this is true. As Clayton Christensen says, when a technology becomes sufficiently complex and expensive then it’s only a matter of time before a new technology rushes in to relieve the pain points. At first, that new technology looks feeble and it won’t solve the problems of most of the existing technology users. Over time, the new technology grows and evolves, eventually gobbling up the entire market. Christensen’s observation, called the Innovator’s Dilemma, was based on research into the disk drive industry. However, the pattern repeats endlessly in many fields. The first microprocessors were laughably puny. The minicomputer vendors looked at them in disdain. Bought any minicomputers lately? How about 8-inch hard drives? How about 7400 series TTL?
IP is clearly a way to relieve a lot of design pain points for complex SoC Realization.
Finally, Jim Hogan writes:
“I mean, what is it really going to take to assemble and integrate all of it together, deal with both hardware and software on a SoC platform, and ensure it’s ready to hand off to the implementation phase?”
Indeed, that is exactly the right question to be asking. At least, it’s one of the right questions to be asking. There are more. For example, what kind of standards can we put in place to make it easier for IP blocks to be used as plug-and-play components? That too is a critical question. TI’s 7400 series devices became de facto standards. We’ve got a more complex compatibility problem with IP blocks and I don’t think de facto standards will work here. One move in this direction is the use of IP-XACT as such a standard. (Jean-Michel Fernandez of Cadence and Cyril Spasevski of Magillem gave a tutorial presentation on IP-XACT at DATE.)
Beyond standards, there’s the question of IP quality. Just as there were high- and not-so-high-quality vendors of TTL chips, there is a quality range with IP vendors. In the TTL days, if you identified a bad 7400 series part, you switched vendors. Things are more complicated with IP. Mistakes in vendor selection cost millions of dollars now, so you want to avoid them if humanly possible.
Then there’s the question of the other pieces of the puzzle that accompany each IP block—namely software drivers and verification IP to prove you’ve used the IP block correctly. An IP block is really not complete, not plug-and-play until you have these as well.
These questions are all important, interesting, and thought-provoking. The answers, when they come, will be more so.