Design Automation Technology Roadmap: The Age of Integration

The 1990s: The Age of Integration

Before EDA tools were commercially available, software architecture standards could be established to assure smooth integration of the tools into complex EDA systems supporting the entire design flow. Choice of languages, database and file exchange formats, host hardware and operating systems, and user interface conventions could be made solely by the developing company. Moreover, the need for compre- hensive EDA systems supporting the entire flow through design and manufacturing release in a managed process is of paramount importance. Design of ICs with hundreds of thousands of gates (growing to hundreds of millions) across a design team requires gigabytes of data contained within thousands of files. All these data must be managed and controlled to assure its correctness and consistency with other design components. Design steps must be carried out and completed in a methodical manner to assure correct- ness of the design before release to manufacturing. The EDA system that encompasses all of this must be efficient, effective, and manageable. This was always a challenge for EDA system integrators, but the use of EDA tools from multiple external vendors compounded the problem. EDA vendors may develop their tools to different user interfaces, database and file formats, computer hardware, and operating systems. In turn, it is the EDA system integrator who must find a way to connect them in a homogeneous flow that is manageable, yet provides the necessary design efficiency across the tools. By the late 1980s it was said that the cost to integrate an EDA tool into the in-house environment was often over twice that of the tool itself. Consequently, the CAD Framework Initiative (CFI) was formed whose charter was to establish software standards for critical interfaces necessary for EDA tool integration. Thus began the era of the EDA Framework.

The EDA Framework [14] is a layer of software function between the EDA tool and the operating system, database, or user. For this software layer CFI defined a set of functional elements, each of which had a standard interface and provided a unique function in support of communication between different tools. The goal was to provide EDA system integrators with the ability to choose EDA tools from different vendors and be able to plug them into a homogeneous system to provide an effective system operation across the entire design flow. The framework components included

• Design information access—a formal description of design elements and a standard set of software functions to access each, called an application program interface (API)

• Design data management—a model and API to provide applications the means to manage concurrent access and configuration of design data

• Intertool communication (ITC)—an API to communicate control information between applications and a standard set of controls (called messages)

• Tool encapsulation (TES)—a standard for specifying the necessary information elements required to integrate a tool into a system such as input files and output files

• Extension language (EL)—specification of a high-level language that can be used external to the EDA tools to access information about the design and perform operations on it.

• Session management—a standard interface used by EDA tools to initiate and terminate their operation and report errata

• Methodology management—APIs used by tools so that they could be integrated into software systems to aid the design methodology management

• User interface—a set of APIs to provide consistency in the graphical user interface (GUI) across tools.

Each of these functional areas needs to be considered for integration of EDA tools and to provide interoperability between them. In its first release, CFI published specifications for design representation (DR) and access, ITC, TES, and EL. Additionally, the use of MOTIF and X-Windows as specified as the GUI toolkit. However, for many practical, business, and human nature reasons, these standards did not achieve widespread adoption across the commercial EDA industry and the “plug-and-play” motto of CFI was not realized. However, the early work at CFI did serve to formalize the science of integration and communication, and a number of the information models developed for the necessary components are used today, but often, slightly modified and within a proprietary interface.

As learned, it was not only expensive to change EDA tools to use a different internal interface or data structures, but it was also not considered good business to allow tools to be integrated into commercial system offerings from competitors. For a period, several framework offerings became available, but these quickly became the product end in themselves rather than a means to an end. These products were marketed as a means to bring outside EDA tools into the environment, but few vendors modified their tools to support this by adopting the CFI specifications. Instead, to meet the need for tool integration, the commercial industry focused on data flow only and chose an approach that provides communication between tools by standard data file formats and sequential data translation. Consequently, EDA flows of the 1990s were typically a disparate set of heterogeneous tools stitched together by the industry-standard data files. These files are created from one tool and translated by another tool (within the design flow) to its internal data structures. Many of these formats evolved from proprietary formats developed within commercial companies that were later transferred or licensed for use across the industry. Common EDA file formats that evolved were

• Electronic data interchange format (EDIF)—netlist exchange (EIA → IEC)

• Physical data exchange format (PDEF)—floor plan exchange (Synopsys → IEEE)

• Standard delay file (SDF)—delay data exchange (Cadence Design Systems → IEEE)

• Standard parasitic exchange file (SPEF)—parasitic data exchange (Cadence Design Systems → IEEE)

• Library exchange file (LEF)—physical characteristics information for a circuit family (Cadence → OpenEDA)

• Data exchange format (DEF)—physical data exchange (Cadence → OpenEDA)

• Library data format (.lib)—ASIC cell characterization (Synopsys)

• ASIC library format (ALF)—ASIC cell characterization (Open Verilog International)

• VISIC high-level design language (VHDL)—behavorial design description language (IEEE)

• Verilog—RTL-level design description language (Cadence Design Systems → IEEE)

These “standard” formats have provided the desired engineering and business autonomy necessary to get adoption and their use across the industry has improved the ability to integrate tools into systems drastically compared with the 1980s. It has proved to be an effective method for the design of today’s commodity ICs above 0.25 µm. However, the inherent ambiguities, translation requirements, rapidly increasing file sizes (owing to increasing IC density), and the fundamental nonincremental sequential nature of design flows based on them will soon give way to IC technology advances.