Competition is good for every industry that I know of, so why would the competition between CCS and ECSM be bad for us? Let the marketplace vote with their dollars and we can settle which version is adopted.
Designers don't attend DAC because they are too busy using old tools to solve their present design. It's the exact same reason they don't have time to see time-saving new tool flows. Budgets are tight and DAC is seen as a fringe benefit.
I agree about opportunistic law firms that are not protecting a legitimate technology patent. I am also shocked at how much EDA intellectual property has been outright stolen, like the infamous Avant! case. Why didn't Jerry Hsu ever do prison time?
EDA software administration has increased in complexity based on direct demands from customers, plus from requirements by EDA companies to "keep honest customers honest" by enforcing contracts. I agree that installation should be as simple as any PC-based software where I merely click on the "Next" button and everything works.
You hit a big point on tool flows. It has been estimated that for every $1 spent on EDA tools that $4 is spent on integrating a working flow.
Mentor used to have a fairly monolithic system in the Falcon framework days, but guess what customers asked for? Standards-based, file-based, tool flows, not monolithic flows.
You failed to mention the common practice of EDA customers to wait until the final 10 days of the quarter to see which EDA vendor will cave-in and give them the best terms for their dollar, further driving down the Average Sales Price of tools. The line goes something like, "I"ve got a PO in my desk drawer for $1.2M and I want unlimited use of all your tools for 3 years. Do we have a deal? If not, your competitor is waiting in the lobby."
Driving the EDA ASPs downward has caused many EDA companies to have flat or declining revenues which leads to fewer resources to fix the issues that you have raised.
I am with an EDA company and I can not agree more with Dale's view on "Competing technology standard" that we have wasted too much resource and money competing on something which should not be an issue to begin with. The consequence? As Daniel points out the customer has to spend 4x as much just to make the flow work.
We as an EDA vendor should recognize the number 1 rule that the customer has the right to pick and chose the best-in-class tools for their design projects. This fundamental requirement goes above and beyond any slick unified DB, framework, etc. Anyone who doesn't understand this basic principle is doomed to fail. Don't get me wrong, the unified DB, framework, platform, whatever you call it, is all great but only if it allows the user to pick and choose best-in-class tools, which more often than not won't be from one vendor.
Knowing this fundamental user's requirement, it's no surprise that Mentor's Falcon and Cadence's OPUS failed miserably and the user still go back to the rudimentary standard file format such as SPICE, LEF/DEF, and GDSII, etc. albeit not as efficient as if they are all on the same DB, but at least these standard file formats allows the user to be able to choose and pick the best tool in class.
The solution? With the claimed openness of Milkyway from Synopsys and OpenAccess from Si2, we may finally see some relief. However, I would like to point out a few serious issues that could make OA ill-fated if these issues were not addressed and fixed soon. OA has a great mission that any OA compliant tools should be able to "plug-and-play". However, what could turn this good will into evil spirit is that some vendor is trying to hijack and cripple the OpenAccess system with yet another proprietary Skill language and constraint format, and what make Si2 double evil is that Si2 committees even allow it to happen.
So My plea here for the benefit of the whole design community is
1. Let us EDA vendors compete on the technology and not on the languages or spec formats.
2. The Si2 committee should ban any vendor who ride on the OA bandwagon and yet unwilling to be OPEN in the first place.
3. The Si2 should stop supporting any claimed proprietary stuff such as Skill language and Constraint management until they become OPEN to the public. Supporting a single vendor's proprietary stuff is a clear contradict and violation to the OA's mission statement.
OA is too good a system to be abused and spoiled by a single vendor.
Silicon Canvas, Inc.
Edited by hau_chen on 10/16/06 02:59 PM.