- Competing technology standards. The latest example of multiple standards for expressing essentially the same information is CCS versus ECSM. These conflicting proposals slow down progress as common conventions are debated instead of being adopted. Since it's likely that most chip designs will utilize EDA software from several vendors, interoperability based on industry-standard information expression and interchange is paramount. This is not to trivialize the tremendous time and effort required to generate, discuss, ratify, and introduce standards. Rather, a plea that EDA companies don't intentionally produce proprietary or redundant standards.
- Lack of designers attending the Design Automation Conference. My totally unscientific survey indicates that CAD personnel dominate this excellent forum that would allow designers to first-hand experience and influence the products for which they are the ultimate consumer. Like road-testing a car, the eventual driver needs to be the one behind the wheel. CAD developers and supporters must continue to attend DAC, but they should bring along some of their customers as well.
- Legal issues dominating over technical innovation. I support patent protection, but despise law firms (“patent trolls”) who suck attention, time, and money away from product development. Revenue recognition and legal departments increasingly overstep their bounds, hampering reasonable business practice and effective product deployment. Please decline your next invitation to join a frivolous class-action lawsuit where the lawyers pocket the vast majority of the settlement.
- Overwhelming EDA software administration. Cumbersome product licensing and CAD tool installation issues are an increasing burden on already scant resources. Legitimate use of software products should be convenient and as easy as “yum install” to install. Instead of being able to use their time to increase designer productivity, system administrators in recent CELUG discussions are by necessity debugging odd license daemon behavior and the differences between colon-separated and comma-separated license server lists. Installation scripts are far from simple and there's no EDA standard for product version nomenclature, environment variable settings, etc.
- Lots of attention focused on point tools but not enough emphasis placed on tool flows. Several different tools are typically part of the design process, yet their sequence and data interaction are too often left for the customer to decipher. Ideally, tools would come packaged with well-documented example scripts that “plug and play” with their counterparts. Data created by one tool would seamlessly be read by the next one in the flow, as well as report whether it created sufficient and quality results for execution by the rest of the flow.
The above comments are general impressions that are not directed at any specific EDA vendor or customer. Intended to provoke thoughtful discussion, my goal is to increase vendor/customer collaboration leading to more productive industry practices. Since the vendors ultimately provide the products, standards, and licensing, and largely, I expect, underwrite DAC expenses, the missing role is that of the customer to keep the EDA suppliers aware of their requirements and concerns. Most vendors welcome customer feedback, and many sponsor user groups or forums. I encourage my fellow customers to take advantage of these opportunities to improve EDA industry capabilities. Vendors and customers should realize the benefits of a competitive and innovative field and not be burdened by its deficiencies.
By
Dale Donchin