Are ESL and DFM false hopes?

The traditional EDA model is to build software packages that can be used by thousands of engineers across many applications. That works for older technologies but not for ESL or DFM, which is why those technologies have become prime areas for in-house tool development. ESL lacks precise definitions, but it can be used to describe activities that take place before RTL coding. The problem with ESL is that it is typically specific to the domain space and the application.

This is why several panelists at the recent Design Automation Conference said they're developing their own ESL tools, partnering with universities or using open-source SystemC tools. This is also why, in the recent EE Times/Deutsche Bank 2005 EDA survey, system-level design was found to be a key area for internal tool development.

With all the hype about ESL tools, electronics OEMs can't find the tools they need in the commercial market. It's not because EDA vendors are lazy; it's because the needs are so company-specific. There is one very successful "generic" ESL tool, and that's Matlab from The Mathworks, but with a price of around $2,000, it's one or two orders of magnitude below what the big EDA vendors are used to.

The problem with DFM is that you have to be close to the foundry. Just getting some packaged DFM rules in a library is no longer enough at 65 nanometers and below. There will be a need for statistical yield modeling and detailed, calibrated process models. Foundries are reluctant to give out the needed proprietary information, so many foundries and IDMs are likely to develop their own DFM tools.

The result is that EDA may have to become more of a services industry. Actively partnering with the people who have the applications-or with the foundries-will be crucial.

---

The Art of Design column offers opinions and perspectives on the technology, techniques and business of electronics design. Its subject matter covers design automation, test, packaging, boards and silicon. Suggestions or comments may be sent to rgoering@cmp.com.