Practical Chip Design

A panel at DAC yesterday examined the future of IP. Panelists included Joachim Kunkel, VP & GM of the Solutions Group at Synopsys; CebaTech's president and CEO Ramana Jampala; Bryan Lewis, research VP and chief analyst at Gartner; Naveed Sherwani, president and CEO of Open-Silicon, SMSC VP engineering Jim O'Connor; and Francios Remond, group design methodology manager at ST Microelectronics. In a wide-ranging discussion with the audience, the panel explored the current nature of IP and its likely future.

One thread of the discussion involved the growing importance of software to IP; or to look at the issue in a slightly different way, software as IP. Both Jampala, whose organization builds system-level tools, and Kunkel, whose organization sells conventional silicon IP, observed that the distinction between hardware and software is getting blurred. To some degree that is because tools like CebaTech's allow system architects to defer hardware-software partitioning decisions until after they have explored the system design space. But Kunkel pointed out that even some interface IP is designed so that users can select hardware or software implementations of particular functions at integration time, making the hardware-software distinction nearly another knob on the IP box.

Other speakers emphasized the growing importance of software IP in creating an SoC. Remond pointed out that today, you can't build a successful product for his market—home entertainment—on either generic hardware or generic software. You have to have innovation in both areas, he said. Yet Lewis said that Gartner's data suggest a gradual rise in the platform-based design concept. Today it means that a company may create one SoC hardware platform chip and spin off a variety of products by making small hardware changes and large software changes. Tomorrow, Lewis said, it may mean that there are only a few platform chips available in an increasingly centralized IC industry, and chip companies will create products by selecting one of the appropriate platform chips, configuring it, and adding software. Thus to a great extent IP will have come to mean software, not hardware, blocks.

Yet there is a financial challenge to this evolution, the panelists observed. O'Connor pointed out that when SMSC designs a chip, they sell it to customers. When they put an even larger investment into driver software, the customers expect it for free. Thus the software portion of the job stays largely unrewarded, limiting the amount of effort chip vendors can justify putting into it. There is a risk that as software becomes more and more a differentiating portion of an IP product, it will remain unable to capture incremental revenue.

A second thread involved the apparent trend for IP blocks to grow in size and complexity—moving from functional blocks to sub-systems. Kunkel said that he is seeing this to some degree even in relatively small interface IP, as customers may request that a cluster of interfaces be packaged into a single block. Remond said that on a larger scale, he is seeing a trend toward functional blocks such as media accelerators growing into media-processing subsystems, possibly including a CPU, several accelerators, and memory. And Lewis pointed again to the growing influence of full platforms in SoC design, in which in effect the platform becomes a single configurable piece of IP.

But panelists agreed that there are also factors acting to limit the growth in the size of IP blocks. One is market size. As blocks grow larger, they also of necessity grow more application-specific, until the total available market for a block begins to shrink. At that point, the wise IP vendor will think twice about further integration that might make the block useful to a narrower, rather than a wider, audience. Another limiting feature, according to Sherwani, is trust. He warned that it would be very difficult for a chip design team to adopt an IP block that was too complex for them to either trust or debug. Since the ultimate responsibility for the operation of the chip falls on the integrator, not the IP vendor, trust in the quality of IP is a vital factor in IP selection.

A further limitation Sherwani pointed out is undercapitalization. He said that SoC designers, of necessity, demand higher and higher quality and greater complexity of IP vendors. And yet the chip vendors are unwilling to grant IP vendors high enough margins to finance either the R/D or the level of verification that chip vendors seem to want. So at some point undercapitalization may become a limiting factor on the growth of independently-designed IP.

A third thread in the discussion was design flows. Sherwani pointed out that our present SoC design flow is essentially an elaboration of the place-and-route flow that dated back to the beginning of ICs. It begins with the assumption of a blank sheet of paper. Yet according to Lewis, greater than half the content in today's SoCs is in fact reused IP. Sherwani said, and other panelists tended to agree, that SoC designers needed a flow that allowed early exploration of hardware/software partitioning, and allowed designers to keep each block at the highest level of abstraction possible for that block through the design flow. Yet Sherwani warned that this level of abstraction would be different for blocks with different levels of trust. And creating a design flow that could really integrate, verify, and close a design composed of blocks that differed in their levels of trust and abstraction was as yet an unsolved problem.

O'Connor and Remond described what might become such a flow. On the architectural side, O'Connor said, it would begin with an architecture built around a central bus with plug-in hardware modules, and would maintain a view of the design as a set of transaction-level models, diving into hardware detail only as necessary. It was suggested that one only needs to get into the RTL on a block either when something isn't working, or when there is a really substantial opportunity to improve the overall chip's power or performance.

Remond added that such a flow would need tools for creating new blocks in C rather than Verilog, and would employ IPXact—as ST, NXP, and TI already do—for automated configuration and assembly of the blocks plugging into the bus. But Remond said that he believed it was still desirable to flatten the design for final closure.