Integrated Design Flows: The 2005 Design Challenge

The convergence of computer and communications applications into a single electronics device and the need to keep pace with Moore's law by designing at ever-smaller geometries places new demands on designers and EDA tools. New physical effects require new design and analysis methods, while the larger design size associated with these geometries drives tools to ever-higher performance and capacity.

To answer the increasing difficulty of designing today's ICs, the prevailing trend in the EDA industry is to cope with growing complexity by creating integrated design flows. Complexity, density, performance, power, signal integrity and yield are all inextricably intertwined and cannot be addressed by flows made up of separate point tools. In such flows, critical errors cannot be identified until late in the design process, and solving one problem often creates another, forcing time-consuming design iterations. With a tightly integrated flow, design issues can be addressed concurrently, allowing designers to achieve better results on more complex designs in less time.

The solution sounds simple—and would be, were it not that most EDA tools are based on different databases. Thus, since each tool uses different design data to do its job, each tool in the flow cannot comprehend what effect its operations have on the rest of the implementation process. The most common approach then has been to create a single database. This approach creates the illusion of enabling simultaneous optimization of power, area, signal integrity, and so on, but creates only a central repository for static storage of data. Without the ability for simultaneous optimization, designers must use highly iterative post-fix methodologies that significantly increase design effort and reduce overall quality of results.

The key to true simultaneous optimization is an in-memory unified data model, quite different from a database. The latter is a static snapshot of data, while a data model is a live, in-memory representation of the design. With a common data model, all design and analysis algorithms can operate at the same time. A common data model truly unites the synthesis and place-and-route flows. Physical information can be provided to the synthesis engines early in the design cycle for faster, more accurate synthesis. Process information from foundries and more-accurate models can be better leveraged to ensure higher yields. Some major EDA vendors have been espousing the benefits of a common database, but this masks the fact that their design systems do not use unified in-memory data. Simultaneous optimization is therefore not possible.

EDA vendors will continue to work to provide a more integrated flow over the next 12-18 months. It will be interesting to see whether they will provide a common data model approach. For most EDA vendors, this will require completely re-architecting their tool flows. The question for 2005: will new capabilities be introduced to the design methodology as an integrated element in an overall simultaneous optimization flow, or added as a post-fix step? If the latter, then the vendor is still basing their design systems on a database methodology, an inherently flawed approach.

About the Authors