EDA database
From Wikipedia, the free encyclopedia
An EDA database is a database specialized for the purpose of electronic design automation. These application specific databases are required because general purpose databases have historically not provided enough performance for EDA applications.
In examining EDA design databases, it is useful to look at EDA tool architecture, to determine which parts are to be considered part of the design database, and which parts are the application levels. In addition to the database itself, many other components are needed for a useful EDA application. Associated with a database are one or more language systems (which, although not directly part of the database, are used by EDA applications such as parameterized cells and user scripts). On top of the database are built the algorithmic engines within the tool (such as timing, placement, routing, or simulation engines ), and the highest level represents the applications built from these component blocks, such as floorplanning. The scope of the design database includes the actual design, library information, technology information, and the set of translators to and from external formats such as Verilog and GDSII.
Contents |
[edit] Mature Design Databases
Many instances of mature design databases exist in the EDA industry, both as a basis for commercial EDA tools as well as proprietary EDA tools developed by the CAD groups of major electronics companies. IBM, Hewlett-Packard, SDA Systems and ECAD (now Cadence Design Systems), High Level Design Systems, and many other companies developed EDA specific databases over the last 20 years, and these continue to be the basis of IC-design systems today. Many of these systems took ideas from university research and successfully productized them. Most of the mature design databases have evolved to the point where they can represent netlist data, layout data, and the ties between the two. They are hierarchical to allow for reuse and smaller designs. They can support styles of layout from digital through pure analog and many styles of mixed-signal design.
[edit] Current Design Databases
[edit] The OpenAccess Design Database
Given the importance of a common design database in the EDA industry, the OpenAccess Coalition has been formed to develop, deploy, and support an open-sourced EDA design database with shared control. The data model presented in the OA DB provides a unified model that currently extends from structural RTL through GDSII-level mask data, and now into the reticle and wafer space. It provides a rich enough capability to support digital, analog, and mixed-signal design data. It provides technology data that can express foundry process design rules through at least 90 nm, contains the definitions of the layers and purposes used in the design, definitions of VIAs and routing rules, definitions of operating points used for analysis, and so on. OA makes extensive use of IC-specific data compression techniques to reduce the memory footprint, to address the size, capacity, and performance problems of previous DBs. As of 2005, OA is the only modern IC database where the implementation is publicly available.
[edit] Open Milkyway
In early 2003 Synopsys decided to open up their Milkyway physical design database, and started the MAP-In (Milkyway Access Program). It is a tried-and-true production-level EDA database, and is known to be written in C. Its internal implementation is not publicly available (or even to MAP-In members), so no comments may be made about the implementation.
[edit] Falcon from Mentor
Another significant design database is Falcon, from Mentor Graphics. This database was one of the first in the industry written in C++. Like Milkyway is for Synopsys, Falcon seems to be a stable and mature platform for Mentor’s IC products. Again, the implementation is not publicly available, so little can be said about its features or performance relative to other industry standards.
[edit] Magma's database
Magma Design Automation’s database is not just a disk format with an API, but is an entire system built around their DB as a central data structure. Again, since the details of the system are not publicly available, a direct comparison of features or performance is not possible. Looking at the capabilities of the Magma tools would indicate that this DB has a similar functionality to OpenAccess, and may be capable of representing behavioral (synthesis input) information.
[edit] Major features of an EDA specific database
An EDA specific database is expected to provide many basic constructs and services. Here is a brief and incomplete list of what is needed:
- Fundamental Features
- The Design (or Cell) as the Basic Unit
- Shapes and Physical Geometry
- Hierarchy
- Connectivity and Hierarchical Connectivity
- General Constructs
- API Forms
- Utility Layer
- Advanced Features
- Parameterized Designs
- Namespaces and Name Mapping
- Place-and-Route Constructs
- Timing and Parasitic Constructs
- Occurrence Models and Logical/Physical Mapping
- Extensibility
- Technology Data
- Layer Definitions
- Design Rules
- Library Data and Structures: Design-Data Management
- Library Organization: From Designs to Disk Files
- Design-Data Management
- Interoperability Models
[edit] References
- Electronic Design Automation For Integrated Circuits Handbook, by Lavagno, Martin, and Scheffer, ISBN 0-8493-3096-3 A survey of the field. This article was derived (with permission) from Volume 2, Chapter 12, Design Databases, author Mark Bales.
