I have sat through numerous keynote speeches by CTOs of semiconductor companies berating the EDA industry for shipping tools that are full of bugs and that are late, not ready enough in advance of the appropriate process node. Of course this is true, and nothing I am going to say is to imply that improvement is impossible. But it is an intrinsic problem, not just laziness or incompetence on the part of EDA vendors.
In an informal setting, that is to say over a beer rather than in front of a large audience, I tell such CTOs that if they want more reliable software then they can simply use an old version of the tools that has been shipping for years. Tools like that get pretty solid. Of course that is simply a glib response since I know that they can’t design 65nm designs with 130nm tools.
So my next suggestion is that the EDA industry could delay shipping new tools for an extra year or so to allow extensive testing. Another glib response since we all know that the tools are already late and even if it were possible to test them extensively without shipping them (what would we use for test data?) the delay would be unacceptable.
There are two reasons for this state of affairs, one technical and one economic.
The technical reason is that it simply isn’t possible to know everything necessary about a new process node far enough ahead of time to allow for a robust development cycle. For example, even with a huge team of people ready to go it is impossible to develop a full suite of technology for 22nm design. We just don’t know everything we need to know to get started and neither do the semiconductor companies and their equipment suppliers. Inevitably the tools will be later than desired and customers would rather have buggy tools now than better tools in six months. It is the EDA version of MacArthur’s dictum that a good plan violently executed now is far better than a pefect plan executed next week. In fact, whatever schedule is chosen, there are always customers lining up to be beta sites, so that they can get their hands on technology earlier, and pressure to ship even earlier even though the tools will be buggier still.
There is also the fact that it is not really possible to develop an EDA tool in a vacuum. There need to be libraries and designs in the process node to be used to test and wring out the code. A new tool is often rock solid on old designs, it is the new bigger more complex designs that break the tools in new ways.
The economic argument is that EDA has to support several process nodes at once and recoup its investment in a timely manner. Those same CTOs who berate EDA companies for not being aggressive enough, work at the same companies that have CAD managers who insist that resources be diverted to back-patching bugs. They want fixes that are already available added back into obsolete (and no longer officially maintained) versions of the software because their design groups haven’t got round to switching. And those CTOs have finance managers who don’t want to increase their budget for leading edge tools only used by the small number of advanced groups.
The effect of all of this is that EDA companies make their money and recoup their investment on processes only when they become mainstream. They cannot afford to make that investment too far ahead of the mainstream for economic reasons as well as technical ones. The fact that the mainstreaming of the most advanced processes is slowing is already starting to strain this model somewhat since it delays the time to payback.
One way to improve the quality of EDA software would be open source. But if undertaken by the major suppliers, this would also destroy their business model and probably thus result in no software at all. However, EDA moves too fast for open source to simply clone the successful products in parallel. The Econtalk podcast with Eric Raymond pointed out another industry that moves fast and where open source has little impact: games. By the time a game is clearly a hit it is too late to start an open source project to clone it. The gaming community will have got bored with that game and moved onto something else by the time the open source free version is complete and widely available.
Other industries don’t have this problem because they don’t move so fast. Technologies in automotive are adopted in decades not a year or two. CAD for automotive has a lot of time to adapt. But EDA is stuck with a very short reaction cycle and even if the ROI was richer, it is not clear that much would change.