Santa Cruz, Calif. -- A growing movement to bring some standardization to foundry process design kits may crack open an analog and custom IC design market long dominated by Cadence Design Systems. But much more remains to be done, say representatives of EDA providers and foundries.

The kits, called PDKs, contain the design rules, device models, schematic symbols, technology files, parameterized cells (p-cells) and fixed layouts that analog and custom digital designers need to design ICs. As of today, specialized PDKs must be created for each process and EDA vendor. And many contain p-cells written in Skill, a language proprietary to Cadence Design Systems, making the p-cells unusable by other vendors' tools.

In an initial step toward PDK standardization, the Silicon Integration Initiative (Si2) is preparing to distribute a standard symbol set that represents active and passive devices. The set, donated by Cadence, was transferred to Si2 from Accellera in June, but the OpenKit Initiative that produced it has apparently not survived.

But most observers really want interoperable p-cells that can be used in any vendor's tool. Startup Ciranova Inc. offered a solution last week that lets users migrate legacy Skill p-cells to any application based on the OpenAccess database (see Oct. 13, page 30). Ciranova had earlier fielded a free online tool that generates new p-cells using the Python programming language.

As of today, however, only a limited number of applications run on OpenAccess, and the database doesn't support all the data needed for the full analog/custom IC design flow. Some industry players have been calling on Cadence to open its Skill language, or to give up Skill and embrace a standard language, such as Python or Tcl for p-cells.

"I think Cadence should open up Skill and put it in a standards body," said Jim Solomon, Cadence founder and a Ciranova director. "The big worry they have is that Skill was a wonderful lock on the customers. Now, in the world of OpenAccess, they've got to get off that idea."

Cadence, it appears, doesn't want to talk about the issue. The company declined to take part in a panel at the recent Synopsys Interoperability Developers' Forum, declined to be interviewed for this article and issued a short statement. In that statement, Cadence said it believed that "supporting truly independent standards bodies that are user-focused, like Si2 and its OpenAccess Coalition (OAC), is critical for allowing standards to take hold and flourish." While it talked about Cadence's support for standards, the statement said nothing about PDKs, p-cells, OpenKit, Ciranova or prospects for opening the Skill language.

"Cadence has a lock on the industry and has no business incentive to rapidly open," said James Spoto, president and CEO of Applied Wave Research (AWR), at the Synopsys forum panel. "We, as an industry, have to do something about that. We're building a Tower of Babel and stifling innovation."

The data is yours
Standardizing PDKs, said Dane Collins, AWR's vice president of operations, means one thing: building PDKs that are interoperable across multiple design tools. "We consider the PDK to be part of the design data," he said. "It's really something the customer should be able to own and carry to any tool set, so you can use the best tools available."

"Customers are currently stuck between a rock and a hard place," said Rich Goldman, vice president of strategic market development at Synopsys. "The PDKs don't support the tools they want to use, and the foundries can't afford to support all the tools."

The cost of developing PDKs is a concern, said Walter Ng, senior director of platform alliances at Chartered Semiconductor. Not only is there a separate PDK for each vendor, he noted, but there are multiple PDKs for each process node. Chartered, for example, builds an RF PDK and a digital baseband PDK at 65 nanometers. While the development is shared with EDA vendors, he said, validation is a burden for foundries.

It has a direct impact on the IC designer, Ng said. "The more we, and they, have to fiddle with getting design enablement in place, the more delayed customers are in getting to tapeout and silicon," he said.

Solomon said the most important reason for PDK standardization is intellectual property (IP) portability and reuse. He also said a lot of "dumb things" haven't been standardized, such as the lack of consistency in the way layers are named.

Getting a checklist
A modest step toward PDK standardization was undertaken by the Fabless Semiconductor Association (FSA) in 2003. It set up a PDK working group that devised a "checklist" of items that should be in a PDK. "It's kind of an ingredients list and nutrition facts label for what's inside a mixed-signal or RF PDK," said Ken Brock, vice president of marketing at Simucad and chair of the PDK working group.

With the checklist, Brock said, design teams can tell what's in the PDK and what needs to be added. Foundries use it internally for quality assurance, he said. The FSA effort has broad support from large foundries, including TSMC, Chartered, UMC and SMIC, Brock noted.

Brock is skeptical, however, about going much further. "Standardizing PDKs across multiple vendors is a difficult thing, especially if you're expecting foundries to do it," he said. He said interoperable p-cells won't be of much help to Simucad, which has its own proprietary language for building its p-cells.

Another attempt at PDK standardization was OpenKit, launched by Accellera in 2003 to develop some standards around schematic symbols and data sets. Nick English, who headed the initiative, said Accellera disbanded it earlier this year. Si2 acquired the Cadence-donated symbol set, which is about all that OpenKit actually produced. English had previously taken a job at Si2 as vice president of development.

English isn't complaining. He feels Si2 is a better place for the symbol set than Accellera, saying Si2 will release the set on its OpenEDA Web site as soon as some legal agreements are in place, hopefully in weeks. But the OpenKit initiative itself is no longer active, he said.

The symbol set is an "important first step," English said, allowing users to move a piece of IP from one PDK to another while maintaining pin information so the schematic remains connected.

Moving p-cells
As it turned out, the first solution for interoperable p-cells came not from a standards body, but from an EDA startup. Early this year, Ciranova rolled out PyCell Studio, a free tool for creating Python-based p-cells for any OpenAccess application, including Cadence's latest Virtuoso IC layout editor release.

But the problem rests with legacy Skill p-cells, and that's where Ciranova's new PCell Xtreme comes in. It migrates layouts generated by Skill p-cells to any OpenAccess application, including Virtuoso competitors such as Silicon Canvas' Laker layout editor. What it actually migrates, however, is the layout generated by a Skill p-cell in the Virtuoso environment, not the parameterized layout generator behind it.

PCell Xtreme is getting attention. "I think it's a huge announcement, and I think it will help open up this part of the design infrastructure," said Chartered's Ng. "It could open up this area quite a bit to startups who didn't have a chance."

Ciranova's products, Solomon said, let users migrate their old Skill p-cells to the tools of their choice, while doing all new development work in an open language, Python. Moreover, he said, Python promises to help automate the creation of PDKs, which has been a painstaking, constantly redone manual process.

While Ciranova offers a step in the right direction, AWR's Collins said, OpenAccess doesn't support the electrical models, parameters and definitions needed by some tools in the analog/mixed-signal flow. Moreover, PCell Xtreme still requires that the user have a Cadence license to generate the layouts. "That really doesn't help us any," Collins said.

Ciranova's offerings are "great news," but they don't solve the whole problem, said Synopsys' Goldman. He thinks Cadence should open Skill, and deliver an OpenAccess Skill evaluator utility. "Virtuoso 6.1 may already support Tcl and Python p-cells, but Cadence continues to promote proprietary Skill p-cells," he said.