Santa Clara, Calif. -- If electronic system-level and design-for-manufacturing tools represent the EDA industry's best opportunities for growth, they need to pack far more capabilities than they do today, users and vendors said at last week's DesignCon conference here. Otherwise, some warned, chip designers will develop their own tools.

"I started writing place-and-route tools when I was in an internal CAD group," said one of the more outspoken users, Richard Tobias, CTO and vice president of engineering at Pixelworks. "Now I'm CTO of a fabless semiconductor company, and I absolutely don't want to build tools in-house--but I have to."

He's not alone, said Gary Smith, vice president and chief analyst at Gartner Dataquest. Introducing a DesignCon "build vs. buy" panel, Smith said that 27 percent of electronic design automation users are now developing in-house tools. Power users always do so, he said, but they represent only 10 to 12 percent of the design community. Thus, anything over that 10 or 12 percent "really should be served by the EDA industry," Smith said.

Tobias said Pixelworks is developing tools in precisely the two areas that many industry watchers see as hot growth opportunities for EDA vendors: electronic system-level (ESL) design and design-for-manufacturing (DFM). Although a few commercial ESL tools exist, Tobias said, they solve "one-tenth of the problem in system design that I'd like to see."

Pixelworks has 5 million to 10 million lines of C code for its HDTV analog subsystems, he noted. "We have to come up with a methodology and tools that allow us to write C code across all different levels of abstraction," Tobias said.

While not yet a showcase for new EDA products or technology, DesignCon offered a technical program rich in content on tools, staging panels on EDA stagnation, verification, DFM and ESL. Most panels combined user and vendor viewpoints.

For system-level design, customers are looking for a number of capabilities, including requirements traceability, early software development, reuse of verification models and behavioral synthesis, Jack Donovan, co-founder of training firm ESLX Inc., said at an ESL panel. But there are obstacles, he noted: Software, hardware and architectural groups have to learn to work as a team, project management has to change and methodologies need to emerge.

Vojin Zivojnovic, vice president for ESL tools at processor-core designer ARM Inc., noted the lack of profiling tools and a standard debugger interface. The industry must embrace collaboration, he said, so that every tool provider won't have a unique way to connect an ARM model to a software debugger. "Today, we can observe that ESL is picking up, but the pace of adoption is still lacking," Zivojnovic said.

Terry Doherty, principal engineer at Emulex Corp., discussed his company's use of transaction-level modeling in SystemC. He called for better tool integration, a SystemC-aware debugger and statistical tools that can profile software and report where it's spending the most time. Doherty also observed that transaction-level models, which might provide 50,000 or 100,000 cycles/second, are still not fast enough for hardware/software co-simulation. He'd like to be in the range of 1 million cycles/s.

Vendor representatives acknowledged that ESL still needs development. Emil Girczyc, CEO of ESL tool supplier Summit Design, noted the many "flavors" of transaction-level modeling, and said the industry needs an agreed-upon level of abstraction. Rindert Schutten, director of system-level solutions for Synopsys Inc.'s verification group, called for system-level intellectual property, a "unified" ESL-to-RTL verification methodology and a "predictable" ESL-to-RTL implementation flow.

That flow would presumably come through behavioral synthesis, offered by companies such as Forte Design Systems and Mentor Graphics Corp. "Almost everybody wants to investigate behavioral synthesis, but nobody wants to commit to it yet," said ESLX's Donovan.

DFM data, tools>
The problem with design-for-manufacturing, Tobias said, is that fabless companies like Pixelworks can't get the yield and defect data they need from foundries. "I really need the aggregate for all wafers produced, and a fabless guy has no access to every wafer that goes through the foundry." Further, he said, "We don't have a DFM interface yet. We don't understand enough, or have enough information, to know . . . what to look at."

Riko Radojcic, principal engineer and leader of the design-to-silicon initiative at Qualcomm Inc., said he gets full support from his foundry partners and doesn't lack yield information. "The issue is what I should do with it." DFM, he said, is a "design transformation related to manufacturing process technology" that is over and above the normal design flow. DFM transformations best take place earlier rather than later in the design phase, he noted.

What Radojcic wants is shape, thickness, performance and yield simulators. "I want these simulators to sit on my desk, so I can optimize my design," he said. In this way, he said, DFM can be analogous to Spice simulation. While DFM today is an "act of faith" based on anecdotes and bad experiences, Radojcic said he hopes to see a "simulated value estimate" soon that will guide DFM transformations.

Ed Wan, senior director of design services marketing for TSMC North America, said that DFM should let designers focus on what's important to them, leaving all the manufacturing issues to the foundry. More specifically, he said, it's about "providing manufacturing variance data to help customers get a better overall yield."

Jean-Marin Brunet, market development manager at Mentor Graphics, said Mentor has created a "design variability index" that designers should try to reduce to zero. "DFM should be measured at the design level with a scoring mechanism," Brunet said.