1. Field of the Invention
This invention relates generally to electronic design automation (EDA) systems used for designing integrated circuits. The invention is more specifically related to a method and apparatus for providing optimization parameters to an EDA logic optimizing tool, and for viewing a number of optimization parameters via an interface.
2. Description of the Prior Art
The design process for all integrated circuits is composed of several discrete operations. Initially, the proposed functionality for a circuit is analyzed by one or more chip designers. These designers define the logical components of the circuit and their interactions by specifying the logic design using design capture tools. These design capture tools are commonly implemented in software executing on an engineering workstation, with well-known input devices being used to receive design information from the chip designer, and output devices, such as computer displays, being used to provide visual feedback of the design to the designer as it is being constructed. Such software is typically implemented as part of an electronic design automation (EDA) system. Specifically, the design entry operation involves generating a description of the logic design to be implemented on the circuit chip in an appropriate machine-readable form. Chip designers generally employ hierarchial design techniques to determine the appropriate selection and interconnection of logic and/or memory devices which will enable the chip to perform the desired function. These techniques involve describing the chip's functionality at various levels of abstraction, ranging from the most general function performed by the chip to the precise functions performed by each logic and/or memory element on the chip.
A common method for specifying the integrated circuit design is the use of hardware description languages. This method allows a circuit designer to specify the circuit at the register transfer level (also known as a "behavior description"). Using this method, the circuit is defined in small building blocks.
Encoding the design in a hardware description language (HDL) is a popular design entry technique used to specify modern integrated circuits. Hardware description languages are specifically developed to aid a designer in describing a circuit. These languages often contain specific functions and syntax to allow complex hardware structures to be described in a compact and efficient way.
It is useful to distinguish between those components of an integrated circuit design called cells, provided by a silicon chip vendor as primitive cells (i.e., leaf candidates), and the user-defined hierarchy blocks built upon them. One way is to speak of a "cell library" vs. a "design library" as two separate libraries, both of which are available to subsequent designs. Alternatively, at least initially, a design library contains a cell library. A cell library is a database containing detailed specifications on the characteristics of each logical component available for use in a design. Initial cell library contents are usually provided by the chip vendor. The components in the cell library are identified by the generic description of the component type. For example, the term "NAND" for a NAND gate is its type description and distinguishes this component from others such as OR gates, flip-flops, multiplexors, and so on. A two-input NAND gate might be of type 2NAND. When a 2NAND component is specified as part of a given circuit design, it is given an instance name, to distinguish it from all other 2NAND gates used in the circuit. The instance name typically includes the instance names of all parent instances by concatenation when defining the instance in the context of the chip.
A single name is sufficient when dealing only in the context of a single user function. The user-defined blocks can then be used to design larger blocks of greater complexity. The user-defined blocks are added to the design library, which grows from the additions of new design modules as the design evolves. The top level of the design hierarchy may be a single block that defines the entire design, and the bottom layer of the hierarchy may consist of leaf cells, the cells (i.e., the logical components) that were originally provided in the cell library. The resulting design is often called a detailed (or gate-level) description of the logic design.
The generation of the detailed description is often accomplished by logic design synthesis software for HDL entry. The logic design synthesis software generates a gate-level description of user-defined input and output logic, and also creates new gate-level logic to implement user-defined logical functions. Typically, the logic design synthesis software is executed many times during the integrated circuit design process, because errors may be detected during the simulation and testing phases of the design cycle and then fixed in the behavioral description.
The output of the design capture and synthesis tools is a logic design database which completely specifies the logical and functional relationships among the components of the design. Once the design has been converted into this form, it may be optimized by sending the logic design database to a logic optimizer tool, typically implemented in software. One such logic optimizer tool is the Design Compiler, commercially available from Synopsys, Inc. The logic optimizer tool may optimize the design in accordance with a user specified optimization strategy. For example, typical logic optimizer tools may optimize selected portions of the design such that the area occupied thereby is minimized, or that the performance of the particular portion is maximized. Other optimization parameters may likewise be provided to the logic optimizer tool. These user specified optimization parameters provide a degree of user control over the logic optimizer tool, and the results produced thereby.
The optimization parameters are typically defined, and associated with, particular modules within a circuit design. For example, the circuit designer may identify those modules that are particularly critical to the performance of the design, including those modules that lie in critical timing paths. The designer may then provide optimization parameters for those modules, wherein the optimization parameters cause the logic optimizer tool to optimize the corresponding modules for maximum performance. Similarly, for those modules of the circuit design that are not in a critical timing path, the designer may provide optimization parameters such that the logic optimizer tool minimizes the area thereof.
Typical logic optimizer tools only optimize one circuit module at a time, starting with the circuit modules at the lowest level in the design hierarchy. Some logic optimizer tools provide a scan capability to scan the design hierarchy, and identify the relative hierarchical position of each circuit module within the overall design hierarchy. Thereafter, the logic optimizer tool may sequentially (i.e. one at a time) optimize each of the circuit modules in the lowest level in the design hierarchy. The logic optimizer tool may then sequentially optimize each of the circuit modules at the next higher level in the design hierarchy. This may be continued until the top level module is optimized.
Because of the sequential nature of the optimization process, it is important for the circuit designer to define the optimization parameters for each circuit module such that the optimization parameter sets are internally consistent with all other optimization parameter sets. That is, it is often left to the circuit designer to ensure that all of the optimization parameters are defined to be collectively self-consistent to achieve an optimum design.
This can be readily understood by considering an example wherein a critical path extends through a circuit design. As indicated above, it is often left to the circuit designer to ensure that the optimization parameters for each of the modules in the critical path are optimized for performance. In addition, it may be left to the circuit designer to compensate for the expected optimization of selected modules within the design. For example, optimizing a first module in a critical path for performance may provide sufficient timing relief, such that a second module in the critical path need not be optimized for performance. Alternatively, optimizing a first module for performance may cause the first module to become excessively large. Because the selection of the optimization parameters is often left to the circuit designer, it may be important for the circuit designer to be aware of the optimization parameters of related circuit modules within a design.
For typical logic optimizer tools, circuit designers may enter the optimization parameters either directly, such as by using a keyboard. That is, the logic optimization tool may prompt the circuit designer for the desired optimization parameters as a particular module is being processed. This method clearly is time-consuming, error prone and tedious.
Alternatively, the circuit designer may enter the optimization parameters directly into a pre-existing behavioral description, which is commonly written for each of the circuit modules, or into a separate script file. That is, the optimization parameters may be added to pre-existing HDL (VHSIC Hardware Description Language) models, wherein a HDL models exists for each of the circuit modules within the design. Similarly, the optimization parameters may be entered via a number of separate script files, wherein each of the number of separate script files correspond to one of the circuit modules. The separate script files are typically entered using a text editor, and may include a number of script commands that can be directly executed by the logic optimizer tool.
Providing the logic optimization parameters in separate script or HDL files for complex designs, having hundreds of modules and many levels of design hierarchy, is often error-prone, tedious and may result in a less than optimal design. That is, entering the parameters into separate script files for each of the modules in the design (either in the HDL code or a separate script file), and thereafter debugging each of the script files can be error prone and tedious.
In addition, because each of the optimization parameter sets are provided in separate files, viewing a number of optimization parameters for related modules is often difficult and/or cumbersome. As indicated above, viewing the optimization parameters for a number of modules within a design is often desirable, since the interplay between the optimization parameters can impact the overall optimized result. Accordingly, an efficient way to view all of the optimization parameters may allow the circuit designers to more easily recognize key relationships between related optimization parameters, and thus may provide a more efficient overall result.
USPTO Backgrounds
USPTO Backgrounds