Design Automation

Delay Calculation Standard and Deep Submicron Design

New standards will improve timing calculations.

By Don Cottrell

At 0.5 µm and below, device properties affect IC design methodologies and tools. With this in mind, today's designer can no longer ignore the effects of device placement during logic design. Likewise, the designer's tools can no longer use simplistic approximation that ignore interconnect effects.

Because interconnect delay effects now exceed cell delay for deep submicron ICs, resistive-inductive-capacitive (RLC) effects need to be modeled to characterize the transient function of each interconnect driver point. Delay characterization must consider state and switching dependencies between the controlling input to a gate and other inputs. Signal slew rates and degradation, or attenuation, as a result of crosstalk must be dealt with in delay characterization.

Figure 1. DCL is a language that allows ASIC suppliers to accurately characterize timing for library cells, and it provides EDA suppliers with the ability to access design-specific information.

While work has been done to define new modeling techniques and extend EDA tools, little has been done on the impact that an individual EDA tool has on a design flow. Delay calculation algorithms often yield different results, and the IC designer using many different EDA tools must determine the delay correlation between these tools. In the end, the designer must determine which result will more closely converge with the post-layout values.

CFI and OVI have addressed these problems with a delay calculation standard and a delay calculation language (DCL).

The DCL approach There are two traditional approaches to delay calculation. The first is to use a fixed delay equation that contains several variables unique to the specific cell and interconnect. Typically, this equation is embedded within the EDA tool and executed on demand, substituting the equation variables with ASIC library-supplied constants and design characteristics. This approach puts the responsibility of defining the proper delay equation with the EDA supplier, rather than the ASIC supplier. Furthermore, as technology advances demand new equation terms or capabilities, more program changes within EDA tools are required.

The second approach is to supply a library of delay look-up tables to the EDA tool. The library will characterize the delay based on different circuit configurations. ASIC vendors supply these look-up tables that are read by the EDA application. Because delay is not a linear function with respect to loading or frequency, interpolation must be used against these sparsely-populated tables. As with the equation approach, table look-up and interpolation is uniquely built into design tools.

DCL provides a new approach to ASIC delay calculation. The architectural goals of DCL include the following:

• Allowing the ASIC supplier to control how delay calculations are performed.
• Leaving the responsibility of design characterization with EDA tool vendors.
• Providing a single, high-performance interface between EDA tools and the ASIC supplier's delay calculation.

The purpose of the DCL approach is to support the following end-customer goals:

• Library developers need only code timing model libraries once for all EDA tools.
• ASIC designers obtain delay values that correlate across disparate EDA tools.
• EDA tool developers have an efficient and effective interface for delay calculation with disparate technology libraries.

The language The DCL approach has a programming-like language to describe delay equations, table descriptions and look-ups, and signal-to-signal test conditions. It has a program to compile source DCL into computer executable format. It also has a software interface for communication of control and data between the compiled DCL and an EDA tool, and vice versa (see Figure 1).

Figure 2. The Delay Calculation System Standard is made up of 4 major components--DCL, DCL-PI, PDEF, and SPEF--that provide an efficient, effective approach to deep submicron characterization strategies.

With this approach, the ASIC supplier may use the DCL language to accurately characterize timing for library cells, and determine the method to account for interconnect. The ASIC library developer decides whether to use table look-up or evaluation of equations. He makes the determination on a cell-by-cell basis, as required. DCL is a functional, high-level language tuned for delay characterization. If DCL syntax does not support a specific need, the compiler allows the library developer to drop down into "C."

DCL The following functions are performed by DCL:

• It specifies computation for both delay and slew.
• It supports both expression evaluation and table look-up.
• It supports min-max, best-case/worst-case, and default specifications.
• It allows for specification of tests for necessary relationships between signals--for example, setup and hold tests for sequential cells.
• It allows for specifications based on signal-edge transitions.
• It allows for specifications based on cell input state dependencies.
• It provides access to the EDA application for design-specific information, including fan-out and fan-in, interconnect parasitics, reduced interconnect models, parallel drivers, and cell clustering (physical proximity).
• It provides the EDA application with intra-cell timing arcs and test criteria; drive-strength cross-over points; computed delays and slews; delay and slew gradient values; necessary base, maximum, and default values; reduced interconnect models; input slew and load defaults; etc.

The DCL compiler DCL is compiled into computer executable format (an object module). By using this object module, computations occur at high speeds on the demand of EDA applications. The object module for a specific technology is distributed as part of the ASIC design library. Shipping only the object module protects the embedded technology characteristics or intellectual property. DCL offers data table encryption for additional intellectual property security.

DCL also considers the need for total life-cycle support of ASIC libraries. It allows the total cell library (DCL program) to be partitioned into program sub-routines that are identified as subrules. Normally, incremental changes are universally redistributed to the design community affected. Updated subrules replace previous versions when the EDA tool loads the object at the ASIC designer's location. Partitioning allows the library developer to structure the library and maximize the use of DCL routines by multiple cells, reducing development and qualification times for multi-cell libraries. In addition, new libraries may be based on previous technology libraries by respecifying the new delays.

The EDA/DCL interface EDA tools dynamically load DCL subrules prior to their execution. During loading, all necessary subrules at the correct version level are loaded and linked together. Loading and linking creates the final executable: the delay calculation module (DCM). The EDA tool invokes the DCM during execution to perform the necessary calculations of delay, slew, etc. A fixed software procedural interface (PI) allows tools to interact with the DCM. Through the PI, the DCM can make requests of the EDA tool, and vice versa. The PI is the "calling" interface to a software function that performs operations on input parameters it receives. The "caller" may be the EDA tool requesting the calculation of a slew value, or it may be the DCM requesting the total number of receivers on a driver's interconnect. Thus, at the heart of the DCL approach is a set of defined calls and callbacks that are dynamically invoked during the EDA tool's execution.

PI and associated functions are (1) open and available to the industry at large; (2) high performance, so as not to degrade overall EDA tool performance; and (3) functionally complete in the services they provide to the EDA tool and the DCM.

The DCL PI can be classified into categories of functions called "explicit" and "implicit." The following provides the characteristics of these functions:

Explicit These functions perform operations within the DCM or the EDA tool that are technology- or design-specific, depending on whether they are EXPOSE or EXTERNAL, respectively. EXPOSE functions are encoded as a DCL statement within the DCL library. They are called by the EDA tool and provide technology-specific information to the EDA tool. The ASIC vendor supplies the EXPOSE functions that are unique to the specific technology in a library. EXTERNAL functions are encoded as part of the EDA tool. They are called by the DCM and provide ASIC design instantiation-specific information to the DCM. The EDA tool developer supplies external functions that are unique to that individual tool.

Implicit These functions are generic and unrelated to any specific technology or design instantiation. They perform service functions necessary for DCM loading and linking, memory management, message management, timing arc modeling, etc. These functions may be called by either the DCM or the EDA tool, depending on the service required. Implicit functions supplied by the EDA tool are distributed as part of the tool. Implicit functions supplied by the DCL compiler are distributed with the DCL-compiled object module technology libraries, which are also referred to as the DCL run-time libraries.

The actual code will vary from supplier to supplier, library to library, tool to tool, or DCL compiler to DCL compiler. The interface PI, however, remains the same, and the function it performs remains constant, as specified in the DCL-PI standard. This standard allows individual companies to use proprietary algorithms and data structures within their designs while adhering to multiple EDA tools (if it is a DCL library) or multiple DCL libraries (if it is an EDA tool).

The remainder of the standard DCL is the heart of the Delay Calculation System (DCS) standard. It provides the ASIC supplier with a single method for describing timing libraries for EDA tools. It also provides EDA tools with a single way to interact with timing libraries. Additionally, DCL makes the ASIC supplier, rather than the EDA tool developers, responsible for device timing characterization and delay calculation. However, DCL alone does not provide a total solution for successful interactions between disparate synthesis, floorplan, and layout tools. Information requested by the DCM from any of these tools is actually created by other tools. For example, synthesis may require clustering information from the floorplanner, or a batch calculator may require detailed interconnect parasitics from layout.

For this reason, there are two other major components of the DCS standard. The first component is a file-based interchange standard for floorplan information. This standard is the physical data exchange format. It provides an open standard for the exchange of floorplan information--the clustering of cells of the instantiated design and associated wire-load models for those clusters. Any EDA tool can read the information and pass it to a DCM upon request for accurate pre-layout delay calculation.

The second component is the standard parasitic exchange file (SPEF), which provides a standard format for the exchange of both detailed parasitics and reduced models--second order pi-models for drivers and pole-residue models for receivers--for detailed delay calculations that accurately account for interconnect layout.

As proposed by CFI and OVI member companies, the entire scope of the DCS standard consists of DCL, DCL-PI, PDEF, and SPEF (see Figure 2). Collectively, these elements provide a comprehensive, accurate and effective approach for timing-driven design tools. Whether used within a design tool, such as synthesis or layout; an analysis tool, such as static timing analysis; or a batch delay calculator, that creates a standard delay format (SDF) to hold delays for simulation; the DCS suite of standards provides a foundation for deep submicron timing closure. Industry-wide use of the DCS standard will provide significant advantages to ASIC suppliers, EDA tool developers, and ASIC designers as they cope with the technological challenges of today and tomorrow.

Don Cottrell is vice-president of Technology, CFI Inc. (Austin, TX).

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@asic.com.

integrated system design  July 1996