At issue is the creation of an API, or of a set of domain-specific APIs, that will allow multiple EDA applications from different sources to operate on shared data in memory. In theory, startup EDA vendors, university researchers, and in-house CAD groups could all plug into such APIs and interoperate directly with mainstream EDA tools, creating a much smoother flow than standard file formats can allow.

Top priority

A standard design-data API has been identified as the top interoperability priority by the Design Technology Council, an ad-hoc group that advises the EDA Industry Council. Terry Blanchard, EDA Industry Council chairman, revealed that a group of six user companies — Motorola, Intel, IBM, Lucent, Hewlett-Packard, and Sun Microsystems — has convened to push for such an API.

"The time to drive this effort is now," Blanchard said. "In my opinion, if we don't have a standard API in 18 months we will have missed the window, and we'll spend the next decade trying to recover and cleaning up the mess."

Mark McDermott, director of Intel Corp.'s Texas Development Center, said he'd like to see most vendor tools and all Intel internal tools conform to a "tightly integrated data model and application usage model" by the 2003-2004 time period.

"We're dealing with a problem that can completely change the design paradigm, unless we can get environments opened up so we can put in proprietary tools," said Gary Smith, chief EDA analyst at Dataquest Inc.

Speakers from LSI Logic, Motorola, IBM, and Ericsson also spoke favorably about the development of standard APIs and data models. "This seems like perhaps the first time ever that, industry-wide, we have agreement on what we need to move forward," said past VHDL International president Steve Schulz, speaking from the audience.

But vendors and some users provided a reality check by enumerating some of the technical challenges of a design-data API. These include the need for a strong semantic foundation, a clearly defined scope, a need to avoid compromising tool performance, an ability to extend and evolve the API, and interoperability with existing standard file formats.

Thomas Daniel, vice president of ASIC technology at LSI Logic, noted that it takes a huge effort today to debug interfaces — and that more effort will be required for in-memory operations. "What we'll need," he said, are "debugging tools on steroids."

Dinesh Bettadapur, vice president of business development for Monterey Design Systems, noted that a standard must include a data model as well as an API — but that the actual databases should be left to vendor implementation.

A design-data model will be "extremely complex," and it must be very flexible and extensible, said Joe Hutt, vice president for R&D at Magma Design Automation. "The data model must be able to handle design requirements not defined or even known at this time," he said.

But much of the discussion centered on the process of developing a standard API. Vendors mostly felt that it should be provided by a vendor, rather than a standards body or committee. "If you take the United Nations approach, you will find it has glacial evolution," warned Kevin Kranen, director of strategic programs at Synopsys. The best solution, he said, is a widely-adopted proprietary standard made available through open-source or community-source licensing.

An API will be difficult to support, and getting an efficient API will be challenging, said John Lee, head of simulation analysis at Avanti. "The best bet is that a large EDA vendor offers a proven solution," he said.

Lack of trust

"I think the fundamental issue is one of trust," said Richard Newton, director of the Gigascale Silicon Research Center, which he volunteered as one group that could help shepherd such a standard. "No one trusts anyone in this industry. Unless we find a way to trust each other at some level we are probably wasting our time," he said.

One way to look at the problem, Newton added, was that there are no 800-pound gorillas in EDA that could force a de facto solution. "We have too many medium-sized players and no Microsofts," he said. Newton suggested users agree to back the first EDA vendor that makes all its interfaces open. "Unless we think radically, I am pessimistic," he said.

In a concluding session, debate raged over whether users would be willing to pay the costs vendors would bear to build interoperability into their products. In a straw poll at the workshop, users unanimously said they would pay those costs. But vendors were dubious.

"Very few users are willing to pay a premium for systems that are interoperable," said Synopsys' Kranen.

"The question is whether there is enough technical value that can be tied together with business interests to make this a success," said Kent Moffat, strategic technology director at Mentor Graphics.

Users countered that they are already paying the costs for the lack of interoperability and are ready to pay those costs up front in products. "Everyone's gone through rewriting code," said Robert McLellan, senior manager of ASIC design technology at Nortel Network.

"I have people calling me up every day to ask 'Are you going to buy this, and are you going to buy that,' " said one Infineon designer. "Now I am going to say if you do not have interoperability, get out of here."

Newton of Gigascale Silicon Research simply pointed to the inherent conflict inside users' companies on the issue. "The managers see the value of the dollars they could save [with interoperable tools], but the guy who needs to build the chip just wants the best tool," he said.