The present invention generally relates to the field of integrated circuits, particularly to a method for creating constraints for integrated circuit design closure.
Creating constraints for integrated circuit design closure that are suitable to all of the tools used to develop and verify an integrated circuit design is a difficult, significantly manual, confusing and error prone task. Constraints are all of the files and directives that are used to guide or drive the design tools. This includes, but is not limited to, Synopsys Design Constraints (SDC), synthesis directives, physical optimization directives, and the like. Tool-specific combinations of each of these kinds of files or directives are used to guide specific tools. However, in a typical design flow there are varying levels of these files supported by each tool and different interpretations of the same directives.
Conventionally, the problem of creating constraints is solved with an ad hoc approach of constraints generation and integration flow. This approach typically involves manually generated specific constraints, tool generated constraints, and constraints that need be customized on an instance basis (e.g., 3rd party IP constraints). This collection of constraints is typically used as a starting point to create constraints that are adjusted manually and/or programmatically by translation based on the needs of the tools and the needs of the design flow.
However, the conventional approach has many disadvantages. First, it is very manually intensive and prone to integration error with manual customization. In addition, translating constraints may result in a loss of information. Moreover, no single tool covers all of the combinations of constraints. Further, different steps in the flow, even using the same tools, often require a unique constraint package. Additionally, tool errors may create the need for temporary constraint modifications. To make things worse, these issues may then combine with a typically serial propagation of constraints from the first tool through the last tool. Moreover, at some stages unique branches need be created, which may generate multiple concurrent maintenance paths. Further, if possible, the flow may require the insertion and removal of constraints, either manually or programmatically, which are specific to one stage versus a previous stage as the constraints propagate. In addition, it is often the case that key constraint-related data is not captured early in the development cycle and need be added via interaction with the originators of the design and the final processors of the design. This is an error prone, iterative and time consuming process, which may reveal, very late in design closure, errors that may trigger a complete restart of the optimization process. This restart may invalidate a significant amount of the logical validation of the design. With all of these issues, the system may become inherently more unstable: the further the constraints proceed through the development flow, the more manual steps are involved.
Thus, it is desirable to provide a method which may address the foregoing described problems.
In an exemplary aspect, the present invention provides a method for creating constraints for integrated circuit design closure. Design specifications are captured before a design flow is started. The design specifications are checked for compatibility with the design flow. The design specifications are stored in a database. Output transforms are applied to the design specifications to create orthogonal constraint sets which are tuned for both a specific tool and a positional use of the specific tool within the design flow.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as claimed. The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate an embodiment of the invention and together with the general description, serve to explain the principles of the invention.
The numerous advantages of the present invention may be better understood by those skilled in the art by reference to the accompanying figures in which:
Reference will now be made in detail to the presently preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings.
Referring now to
The clock specifications 102 identify the clocks or clock like functions and the required characteristics associated with them. For example, a clock typically has characteristics such as frequency, duty cycle and uncertainty as some base characteristics. The clock specification often also includes characteristics that describe their relationships to other clocks. For example, a clock may need to have a coincident edge with one or more clocks, or it may have a start up logical relationship with those clocks (e.g., when three clocks that have been related by an edge need to all become active coming out of reset on the same edge). The IP specifications 104 are a localized set of the same kinds of specifications that are in the reset of the design.
The I/O specifications 106 describe the characteristics associated with the I/O. These may include specifications indicating when a signal propagating to/from an I/O needs to be valid. They may further specify the valid time to rising or valid time to falling. They often include characteristics that describe their relationships to other I/O or to clocks. For example, a set of I/O may need to propagate their signal such that all of the valid values across them occur within a window of time. I/O's may also have a relationship with a clock in that their valid propagation time is relative to a specific clock.
The tool specifications 108 are the expression of the capabilities and requirements of the design flow and the tools within it in the context of the overall goals of the system. The tools in the flow may require custom files that are not part of a recognized standard. For example, a tool may require a file that explicitly describes a relationship between two clocks. Another example may be supplying a set of rules specifications that bound what the design system may accomplish using that tool. The tool may not be able to effectively optimize specific design scenarios (e.g., the tool may not effectively deliver a specific edge relationship between clocks. These restrictions may feed into specification validation).
The exception specifications 110 are specific requirements within a design that are explicitly captured directly with I/O or clock specifications. An example of this is a case where a register in a design is used exclusively as a set up register. This means that the timing paths that emanate from this register may have relaxed requirements. Another case is when specific paths within the design may never be exercised, where checking of the timing on these paths may be disabled.
The modal configuration specifications 112 control the functional configuration of a design. For example, the design may have multiple functional capabilities overlaid on a common single set of hardware. Each of these functional configurations results in a set of functional modes. These specifications govern how these modes are activated. For example, a clock in the design may have a mux that controls its clock source. In one mode one branch of the mux is the clock source, and in another mode the other branch of the mux is the clock source. Thus, the pin that controls the mux is the mode control. Another example is where a programmable divider is used to create a clock. Thus, the pins that control the size of the division are the mode controls. The modal specification is the state information associated with all of the internal and external mode controls. =p The design specifications are checked for compatibility with the design flow 114. The design specifications are stored in a database or other data storage format 116. The specifications that are stored in the database may then be transformed using a script and/or program, or a set of scripts/programs. This body of code is applied to the design specifications to create orthogonal constraint sets 118 which are tuned for both a specific tool and a positional use of the specific tool within the design flow (i.e., tool and flow specific constraints) 120.
If the answer is yes, synthesis constraints are generated 210 based on the specification database 212 obtained in the step 116 shown in
Although
Thus, in accordance with the present invention, design specifications may be utilized in the source constraint generation, constraints may be independently created for each tool in the design flow in the context of the flow step, constraint generation may span the entire end to end (front end to back end) flow, and specification checking may be utilized to check for design system compliance, which may facilitate the identification and handling of exceptions.
The present invention may provide the following advantages in the management and creation of constraints. First, the present invention may directly create the tool correct and flow step appropriate constraints without serial translation, sequential insertion/removal, multiple maintenance threads, the loss of information due to different constraint support and interpretation on a tool by tool basis, or manual/programmatic custom modification to correct for serial translation error. In addition, the present invention may remove the late cycle iteration and risk associated with the late collection and may use key design specifications. Moreover, the present invention may induce great stability since changes in the local tool and flow specific constraints may not propagate to the other tool and flow stages. Further, up front specification checking may provide for additional certainty, where if all the specification requirements are met the entire flow may run smoothly. Where full compliance is not possible, the exceptions may be captured to enable effective up front handling.
It is to be noted that the foregoing described embodiments according to the present invention may be conveniently implemented using conventional general purpose digital computers programmed according to the teachings of the present specification, as will be apparent to those skilled in the computer art. Appropriate software coding may readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art.
It is to be understood that the present invention may be conveniently implemented in forms of a software package. Such a software package may be a computer program product which employs a computer-readable storage medium including stored computer code which is used to program a computer to perform the disclosed function and process of the present invention. The computer-readable medium may include, but is not limited to, any type of conventional floppy disk, optical disk, CD-ROM, magneto-optical disk, ROM, RAM, EPROM, EEPROM, magnetic or optical card, or any other suitable media for storing electronic instructions.
It is understood that the specific order or hierarchy of steps in the processes disclosed is an example of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged while remaining within the scope of the present invention. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
It is believed that the present invention and many of its attendant advantages will be understood by the foregoing description. It is also believed that it will be apparent that various changes may be made in the form, construction and arrangement of the components thereof without departing from the scope and spirit of the invention or without sacrificing all of its material advantages. The form herein before described being merely an explanatory embodiment thereof, it is the intention of the following claims to encompass and include such changes.