1. Field of the Invention
The present invention relates to the field electronic design automation (EDA). More specifically, embodiments of the present invention relate to a flow definition language for designing integrated circuit flows.
2. Related Art
An electronic design automation (EDA) system is a computer system used for designing integrated circuit (IC) devices. The rapid growth of the complexity of modern electronic circuits has forced electronic circuit designers to rely upon computer programs to assist or automate most steps of this design process. Typical circuits today contain hundreds of thousands or millions of individual pieces or “cells.” Such a design is too large for a circuit designer or even an engineering team of designers to manage effectively without computer systems.
In general, the EDA system typically receives one or more high level behavioral descriptions of an IC device (e.g., in HDL languages like VHDL, Verilog, etc.) and translates this high level design language description into netlists of various levels of abstraction. At a higher level of abstraction, a generic netlist is typically produced based on technology independent primitives. A netlist is a logical description of the electronic circuit which specifies what cells compose the circuit and which pins of which cells are to be connected together using wires (“nets”).
The netlist does not specify where on a circuit board or silicon chip the cells are placed or where the wires run which connect them together. In general, a netlist describes the logical IC design and is composed of nodes (elements) and edges, e.g., connections between nodes, and can be represented using a directed cyclic graph structure having nodes which are connected to each other with signal lines. Further processing is needed to generate a geometric database needed for fabrication of the IC design.
Once the logical design or netlist is generated, given a set of design requirements (e.g., die size, timing, etc.) a large number of “tasks” in design tools are performed to complete the physical layout of each of the blocks in an IC design. Each task is a discrete unit of work. For instance, a placement and route processes can be performed. The placement process finds approximate cell locations which optimize desired metrics and spread cells evenly across the silicon chip or circuit board. In this case, the tasks generate geometric information that determine the actual physical size, dimensions, geometry and placement of cells within blocks of the IC design. Also, a routing process is performed for routing wires within the blocks of the IC design. In this case, the tasks generate wire geometry for routing the wires. The wire geometry data structure and cell placement together are used to make the final geometric database needed for fabrication of the circuit.
In executing the above tasks needed to generate the physical design layout of the IC design, many low level commands with associated parameters, options, variables and target databases are required. In some instances, up one-thousand of these commands may be required to place one block in an IC design. Moreover, separate sets of commands are required for each block that is to be processed. As a result, multiple sets of commands are required for each physical design process, which are repeated over each block. In short, the actual command set required by the designer to place and route a netlist may require tens of thousands of low level commands or tasks which need to be executed by the physical design tools in a particular order.
In an effort to address the daunting task of managing these commands, chip designers have written small “build” programs that function to access a block of the netlist and depending on which block is obtained, apply a predetermined set of commands to the block involving the physical design tools. This set of commands is applied to each block of an IC design. However, the computer time required to perform a place and route on a typical IC design is very long. Should there be a problem with the execute program, the placement or routing of the netlist, or in one of the commands, the entire execute program needs to be re-run from scratch once the problem is isolated and fixed. Therefore, this prior art approach is not very efficient in the face of design errors or program bugs which are always present. Furthermore, although this prior art approach helps to automate some of the designer's job, it still requires that in the development or modification of the execute program, the designer needs to use and edit the low level, voluminous detailed commands. As such, this development process can be tedious, error-prone and time consuming.
Another prior approach to solving the problem of dealing with these low level commands is utilize a program such as UNIX Make, which is well known and commercially available. The program, Make, allows dependency graphs to be used indicating the input and the output of certain nodes, with each node representing a design tool task to be performed. Although offering efficient executions, this prior approach requires that the entire physical design process be hand-coded at each of the low level commands required of the design tools. For instance, to run the same design tool over various blocks requires that the same code be block copied for each block, e.g., using an editor. To change a variable or parameter within the design tools requires that the code portion relating to that design tools be identified and manually modified. As such, the Make program does not offer any flexibility in dealing with similar blocks or in adding or deleting or modifying commands because any such activity must be performed by hand, with an editor, directly on the low level commands. This approach is very tedious, error-prone and time consuming.
Moreover, the Make program is well suited for dependency graphs arranged in horizontal fashion (2 to 3 tasks deep, and many dependency graphs in parallel). However, task sequences can be more vertical with many tasks to be performed in sequential order for far fewer dependency graphs. In this case, errors introduced up front in the order are propagated throughout the dependency graph. Again, this approach is very tedious, error-prone and time consuming.
As a result, traditional techniques for controlling the execution of tasks needed to complete a physical design are tedious, error-prone, and time consuming in that commands are created at the lowest levels no matter the dependency or redundancy of levels.