SAN JOSE, Calif. The process design kits (PDKs) issued by foundries to chip designers are difficult to keep current, and may place too much reliance on design rules, according to panelists at the International Symposium on Quality Electronic Design (ISQED) here March 22.
The panel was convened to determine whether PDKs can help achieve better yields, and pass information to the tool flow that would aid in design for manufacturing. But the panel turned into a more general indictment of the state of PDKs today.
John Kibarian, president and CEO of PDF Solutions, led the attack with a list of myths about PDKs. It is a myth, Kibarian said, that design rules can provide a formula for better yield. Yield comes from interactions and tradeoffs between design and manufacturing, he said, and now lies outside the scope of mere rules.
Further, Kibarian warned that modern processes and the contents of their PDKs shift rapidly over time. The job of the designer is not simply to comply with the rules in the design kit as they stand today, but to anticipate how rules, variations and guardbands will change and to "intercept the process at the point where it reaches volume production."
Dan Hillman, vice president of operations at Virtual Silicon, joined in the attack with his own experience as an IP developer. "The big problem is keeping our models current with the ever-changing process," Hillman said. "It takes about 9 months from the time we get a new tech file from the foundry to the time we can see silicon to validate it. But the tech files keep changing. We are still seeing changes to the files for 0.18-micron processes."
Hillman also warned of the growing complexity of device libraries. "There are about 30 device models for most 130 nm processes," he said. "For one 90 nm process we looked at there are 90 device models."
Finally, Hillman gave a warning to silicon IP users. With the growing complexity and rate of change in processes, IP vendors will be unable to keep their IP current with the process, he said. "It's very likely that the IP you use will have been developed with a different PDK from the one you are using. That will be trouble."
Richard Siemiatkowski, former president of EECAD, offered a similar view, stating that the biggest issue with PDKs and the designs built using them was revision control. He observed that by the time an SoC with mixed-signal content was done, it might well have used at least seven different PDKs, assuming no changes during the design. This puts a huge burden on making sure that the versions of PDKs, tools and design views are all kept current, he warned.
Frank Ramsay, director of ASIC technology at Toshiba, offered a particularly pessimistic summary of these views. He argued that in fact the inability of the rules-based PDK to convey enough information to the design team was breaking the entire foundry model. Design for yield could only be done successfully, he argued, with a large, experienced staff in an intimate relationship with the process engineers basically, only in an integrated device manufacturer.
Two panelists offered more optimistic views. Nick English, chairman of the Open Kit Initiative, an Accellera-sponsored program to develop basic guidelines for PDK content and format, said that for many designers, simply fixing the mess that lay beneath the surface of the PDK would be a big help.
"If we could just get agreement on symbol sets, modeling interfaces and the like, engineers wouldn't have to rebuild the PDK before they could start using it," he said.
Paul Koch, engineering group directory at Cadence, admitted that PDKs couldn't tell you everything you needed to know about a design. But they can be a vehicle for conveying a lot of valuable information, he argued.
"PDKs have come to be the the common interface between foundry, EDA vendor and design team at the level between device design and circuit design," he noted. Koch also suggested that automatic PDK generators, driven by process variables and tool requirements as inputs, could ease the problem of rapid revisions of PDKs by at least eliminating a lot of human errors from them.
And David Lan, senior manager for methodology at TSMC, offered a glimpse into the foundry perspective. Lan said TSMC was acutely aware of the problems that recommended rules had created for designers. "There are many 'recommended' rules," he said. "Some are mandatory, and some are less important. We need a way of conveying the priority in a given design."
For example, he said that TSMC is actively working on a way for customers to check their design data files after insertion of resolution enhancement features, not only for correctness and appropriateness, but to analyze the performance of the design as it would be fabricated.
Kibarian said the industry had to go even further. "The whole concept of design rules has broken down," he argued. "You have so many." In fact, Ramsay said earlier that there were 650 design rules for his 90 nm process.
"Not only are there so many rules, but when you dig into them you find out that they contradict each other," Kibarian said. "We looked closely at a 90 nm process recently, and we concluded that if we followed all the rules, we would be designing somewhere between 130 nm and 90 nm, not in a real 90 nm geometry. What would be the point of that? The only solution is to move from rules to a yield simulation approach, where you can do experiments and see the effect on yield."
In the question and answer period one questioner raised the issue of PDKs, design rules and third-party IP. If a foundry creates a rule set, an IP developer applies it to his IP, and an SoC design team uses the IP, each of these parties may want to change the rules, the questioner observed. But who owns them?
After some spirited discussion it was concluded, uneasily, that at the end of the day the foundry owned the design rules, because the only real input to the rules came from the process. But the end design team owned that is, was responsible for the yield. The IP vendor in the middle would more than likely wash their hands of the whole issue. And that separation, it was suggested, was the crux of the problem.