By Joe Santos
Cadence Design Systems Inc.

While I was gone, Cadence Design Systems set the goal to create Open­Access, an open, standard database for EDA. I had left Cadence in 1995 to co-found a virtual reality-based entertainment company. We invested 100 man-years and blew through $10 million on a cool system that never made a dime. I was crushed when we closed. But, in hindsight, that experience helped shape Open­Access. I had learned a crucial lesson about innovation: If your creation never sees the light of day, it doesn’t matter how good it is.

In 1999, Cadence asked me to build a new database. The chance to build a key piece of infrastructure from the bottom up was intriguing. Over the years, I’d experienced the problems that occur when independently designed software modules must be linked. And I had suffered the wrath of customers when important capabilities proved unnecessarily difficult to use because tools did not communicate.

This became a primary driver behind the OpenAccess technology: We knew all the powerful innovations that could be enabled if we could just get EDA tools to work together at a tightly integrated level.

Although we had to clear technical hurdles while creating OpenAccess, the biggest was the disruptive nature of the project. Using OpenAccess requires that groups relinquish some control of their database infrastructure. The reasoning is that it is better for the industry and its customers if we cooperate on the infrastructure so that we can provide better solutions on top of it. The solutions are where we should compete.

Still, there were strong objections within Cadence that we were opening ourselves up to competitors that would use our own database against us. This was particularly ironic because, at the same time, users, competitors and industry pundits assumed Open­Access was either just a lot of talk or some kind of nefarious bait and switch.

In designing the data model and API, disruption was unavoidable. We spent countless hours attempting to negotiate and address the needs of all applications. We had to reconcile not only all the data-modeling issues but also the requirements from both legacy apps and cutting-edge startups.

It was interesting to see the wide range of responses from developers. Some offered suggestions to improve our design while modifying their own code to fit the OpenAccess model. Others were unwilling to make any compromises; to them, the world started and ended with their point tool.

OpenAccess uses technologies that are relatively uncommon in the EDA world, a fact that caused a fair amount of disruption. Concepts like data hiding and encapsulation are fundamental to an object-oriented language like C++ but make a lot of EDA engineers uncomfortable. One reason I’ve had so much fun building OpenAccess is that it has greatly improved the coding expertise of so many of the people involved—including my own.

Of course, that OpenAccess has been donated to the industry is itself a disruptive event. Although most everyone is familiar with the concept of open-source code, few have internalized the responsibilities it imposes on the community, much less decided what to do with the opportunities it offers. It will be exactly as good as we all choose to make it. It remains to be seen whether the EDA industry is up to the task, but I am hopeful for its future.