Post a Comment
Cadence executive cogitates future of IC design
We need whole new kinds of flows to deal with the realities of IC design today, Nimish Modi suggests.
By Ron Wilson, Executive Editor -- EDN, 5/18/2009
With Cadence Design Systems consolidation of over a dozen R/D groups into two, senior R/D vice president Nimish Modi find himself responsible for all the font-end tool development—including the new C-to-Silicon ESL tool, synthesis tools, functional verification, and Cadence's Solutions packages. Under president and CEO Lip-Bu Tan's direction, development organizations that in some cases reflected historical acquisitions more than conscious organizational decisions are getting molded into something more functional. But the organization is more than just an operating convenience; it is an attempt to reflect an entirely new structure in the design flow. Modi spoke about three aspects of this emerging order.
The first aspect is interdependency. For years the industry has discussed the growing need for back-end tools to have access to manufacturing data. But it's gone beyond that. Virtually all the major tools in a modern flow need to exchange significant amounts of data with other tools, and not just on the back-end. Synthesis tools need extraction data, timing estimates, congestion warnings, and DfM data in order to produce netlists that the back-end can use efficiently. ESL tools need to see what synthesis will do in order to create useful RTL. Verification tools may need profiling and constraint data from application software in order to estimate functional coverage and create test cases.
What had been a pipeline of discrete stages is becoming a two-way street, laden with side-roads, loop-backs, fly-overs, and construction zones. Tools require tight integration, not only to pass large amounts of data, but also to invoke each other. The old regimen of separate pipeline stages linked by defined file formats is collapsing.
"There's too much information passing between tools now for us to keep piecing together flows out of best-in-class tools," Modi said. "Increasingly, design managers are seeking optimized full flows and not asking which tool is best at a particular point."
Coming from a Cadence executive that could be a self-serving observation, of course. But Modi is not just asserting the trend, he is concerned about it on two counts. First, he worries about the impact on designers. "I started out as a logic designer," Modi said. "I didn't need to understand metal-fill rules or lithography, or even software. But now it's getting harder for designers to learn all that they have to know for their part of the job. We need different training for front-end designers, to give them more breadth of knowledge.
"For instance," he continued, " we look at who is using the C-to-Silicon tool today. Is it a software engineer who has had to learn a lot about hardware, or is it a logic designer who has had to learn serious software-development skills? For sure it is not a specialist in one area or the other."
Modi's second concern is about the structure of the industry. "In the past, a lot of the innovation in EDA happened outside the big companies. This was quite a culture shock for me, coming from Intel," Modi explained.
But as tools get more tightly integrated, how do those innovative startups work closely enough with big competitors to produce a tool that can exchange data directly with other companies' products? It appears that either the industry will have to go through another round of defining inter-tool file formats, or it will have to vastly expand the concept of Open Access to create a core database fast enough to serve data in increments to a running tool invoked within another tool.
The only alternative seems to be the end of the EDA startup culture, forcing the big companies to learn to innovate internally. Modi has an idea what will actually happen. "One data point," he said, "is that C-to-Silicon was developed entirely within Cadence, not based on work from a startup."
From synthesis to IP integration
A second aspect of the new order is a fundamental change in the way chips are created. "Today, about 70 percent of the average IC consists of reused IP," Modi said. "Increasingly, flows that create new designs are used to create blocks, not whole chips. Design teams create chips by integrating IP, not by synthesizing and verifying huge piles of new RTL."
But Modi is concerned that design flows haven't changed to reflect this evolution. "There is a growing need for an IP integration platform," he said. "Perhaps something can be based on the SPIRIT IP-XACT work." There is some question as to whether SPIRIT and IP-XACT can survive the major changes that seem to be going on within NXP, which company was essential to the birth of the technology. But Modi observed that the industry must have some kind of IP assembly methodology, and IP-XACT is already there.
Finally, Modi discussed the increasingly incremental nature of design work. With the cost of a complete major chip design now approaching three digits' in millions of dollars, design teams are minimizing the number of completely new designs they undertake. Instead, they are using one design cycle to produce a platform design, from which they will draw enough tape-outs for several generations of products.
These platform designs may include all the IP necessary for several generations of chips, with switches to control instanciation of specific blocks, sizes of RAMs, and interface options. Architects may even include two competing versions of the same block—one tried and trusted, and the other potentially faster or lower-power, but untested. If the new block works, great. If not, the old block is only a register setting, or at worst a metal fuse, away, and the company can meet its schedule with a slightly lower-spec chip.
Thus after the platform is verified, additional tapeouts require only incremental changes to the design. Ideally, there would be a full system-to-GDS-II flow that would process changes incrementally—not requiring a full synthesis, verification, place-and-route, and so on just because a couple of blocks changed. The hardest nut to crack in this flow may be verification, where even small incremental changes raise the specter of unintended consequences elsewhere on the die.
There is movement in this direction, Modi suggested. "In the verification space, for instance, our Conformal ECO tool is selling like a house afire." The tool uses formal-proof methods to test the assertion that an ECO has not altered the behavior of a design. By listing the counterexamples to this assertion, the tool shows the exact effects of the ECO. "You can even use it for post-mask ECOs," Modi said, "to verify what actually happens if you wire in those spare gates." Such an incremental approach to verification is a step along the road to a full incremental flow.
The challenges today involve not just more complex designs and nastier processes, but changes in the way design teams must work. They may require new kinds of flows, and even new organization in the EDA industry. It's not going to be five years of more of the same, for any one.
