Patent Application
20070234253
The invention relates to the field of Electronic Design Automation, and more particularly, to a method and a system for performing a static timing analysis on digital transistor circuits.
For many years, the performance of digital machine designs has been evaluated by performing static timing analysis on the designs. Timing Analysis is a design automation tool that provides an alternative to the hardware debugging of timing problems. This program is intended to establish whether all paths within the design meet stated timing criteria, i.e., whether data signals arrive at storage elements early enough for valid gating but not so early as to cause premature gating.
Propagation segments, timing points, the timing graph, arrival times, and timing models:
R. B. Hitchcock, et al., in the article “Timing Analysis of Computer Hardware” published in the IBM J. Res. Develop., Vol. 26, No. 1, January 1982, pp 100-105, and in U.S. Pat. No. 4,263,651, “Method for determining the characteristics of a logic block graph diagram” to Donath et al., there is described a method for providing an indication of path delays between the blocks, in which the output of the program includes a slack at each block to provide a measure of the severity of the timing problems. The program also generates standard deviations for the times so that a statistical timing design can be produced rather than a worst case approach.
In this analysis, the flow of signals through the machine and the delay of the signals, is modeled by a graph of propagation segments referred to as ‘psegs’, each of which describes a delay in the design. By way of example,
Test segments:
In addition to circuits that perform logical operations and delay signals passing through them, certain types of circuits, such as flip-flops, require that signals arrive in a certain order at their inputs. For example, for data to be stored in a flip-flop, any signal transition on the data input must occur before the clock transition. In fact, the data transition must be prior to the clock transition by a length of time referred to as the setup time. Physically, this is necessary so that, during the clock transition, input data is stable at the valid logical value which is to be latched in the flip-flop, and this is only true after the latest possible data transition is over. In terms of the static timing analysis software, this requires that the data AT be less than the clock AT by at least the setup time. In the timing graph, it is represented by an edge between the data and clock timing points referred to as a “test segment” or tseg. During static timing analysis, once the ATs have been calculated for all timing points, each tseg is checked to determine whether the design satisfies the timing requirement that it represents.
Automatic Timing Model Construction:
In order to perform static timing analysis on a digital design described by a large network of transistors, it is necessary to break the network into partitions and to construct a timing model for each of them. Generally, the network is partitioned into channel-connected-components, CCCs. These are sets of transistors which are interconnected by source and drain (channel) connections, albeit not connections spanning through power supply and ground nets. The task of constructing a timing model for each of the CCCs can have varying complexity, primarily depending on the complexity of the CCC. For example, for a simple combinational CCC, such as a 2-input NOR gate of
Static Timing Analysis and Simulation:
During a static timing analysis, one parameter that is required is the delay through each pseg. For a design consisting of transistors, one way to obtain this information is to perform a simulation on each CCC, measuring the time from when, e.g., each input rises or falls through 50% of the supply voltage until the time when the output rises or falls through 50% of the same voltage. One of the tasks necessary to run these simulations is to properly set up all the input voltages to the CCC and, in some cases, to initialize locations within the CCC or at the CCC's output(s) to certain voltages. Referring again to the previously described example of the 2-input NOR gate having two inputs A and B and output Z, in order to simulate the delay on the pseg from A to Z with a rising signal at A producing a falling signal at Z, while the simulation obviously is required to include a rising voltage source on A, it is also required to set input B at low with a voltage source or a topological connection to ground in the simulation. Depending on the simulator, it may or may not also require for output Z to be initialized high and then left to fall during the simulation. The set of these input voltage settings and node initializations is referred to as a sensitization. Each CCC's psegs requires sensitizations for each delay to be computed.
Automatically Generating Sensitizations:
Current programs can construct sensitizations for their psegs in straightforward cases, and can exploit the same kind of local information that is used to construct the timing model for a CCC. One such technique is simply to use a logic simulator to examine each possible combination of inputs and see which combinations successfully produce a transition on the output. Again, for the previous example of the 2-input NOR gate with inputs A and B and output Z, when the code is attempting to build a pseg from A to Z when attempting to find sensitizations including a rising input on A, the code examines the two possible choices for B, low and high, and finds that only setting B low provides a successful (falling) transition on Z, therefore the code captures the combination of A rising and B falling as a sensitization for this pseg. Current programs also exploit user-supplied local information, e.g., a logic low on B, by accepting only those sensitizations that are consistent with all of the local information.
Timing templates:
Not all the timing models and their psegs' associated sensitizations can be built easily with user-supplied local information. Current programs supply another mechanism referred to as templates, where the user explicitly describes each pseg and tseg in the timing model of the problem CCC, and describes each sensitization for each of the psegs. This provides the user with complete control over the timing analysis performed on the CCC, but it requires voluminous user input to achieve this control. The mechanism for controlling these commands is the well-known technique of extending a Tcl interpreter, details of which are found in the textbook “Practical Programming in Tcl and Tk” by Brent B. Welch published by Prentice-Hall 1997, 2000. Furthermore, additional commands can be incorporated which load the pseg, tseg, and sensitization data structures from the options in the Tcl command without calling automatic timing model construction or automatic sensitization construction.
Practitioners of the art will readily recognize that serious difficulties exist by having the user explicitly specify the psegs, tsegs, and sensitizations with templates that create significant problems in that the volume of user input required can easily become extremely large.
When the user specifies local information, such as logical constants, net constraints, and transistor directions, as previously described, difficulties are encountered in instances where the circuit operation can only be described by incompatible sets of local information that cannot be modeled together. For instance, if one mode requires that two inputs pins be treated as logically equivalent, while another mode requires that the same two input pins be treated as logically complementary, then these two incompatible net constraints cannot both be satisfied by specifying simple local information in a single timing run.
Continually inventing new types of local information to describe what would otherwise be incompatible sets of local information presents problems. For instance, in the example illustrated above, one might invent a new type of logical constraint which asserts that two inputs always switch concurrently, but which are to be examined when both switch in the same direction in some instances, and switch in the opposite direction in others. This has the difficulty that there are a very large number of possible combinations of local information, and adding separate commands and support for each combination requires excessive programming effort.
In U.S. Pat. No. 6,760,894 to Yalcin, et al., there is described a method for performing a timing analysis using a set of modes, each consisting of a set of logical constants applied to the control inputs of circuit blocks, and calculating and storing a fixed delay for each path through the circuit block for each such mode. The method described creates psegs directly from circuit block inputs to outputs, as shown by the paths illustrated in the patent's
A difficulty of restricting modes to sets of logical constants on control inputs as described by Yalcin et al., is that it is also useful to be able to specify modes which include logical constants on data inputs, the specification of certain transistors as being ignored during the analysis of the mode, the specification of the direction of data propagation through certain transistors, the specification of logical constraints on sets of inputs, and the specification of certain latch ports as transparent (level-sensitive) or non-transparent (edge-triggered).
A further difficulty of limiting the description of paths in a timing model to fixed delay numbers is that it is also useful to allow precise response of the timing model to variations in loading to input waveform shape, to variations in environmental parameters, such as voltage and temperature, and to variations in transistor characteristics such as those due to process drift.
Still another difficulty exists of limiting the paths in the timing model to paths directly from circuit inputs to circuit outputs is that it is also useful to apply timing-point-specific timing controls, such as phase renames, separately to the timing models of each mode. This last point is described in more detail in the detailed description of the invention.
Accordingly, it is an object of the invention to provide a method for enabling a user to control a static timing model of a digital transistor circuit, particularly, when timing templates are required.
It is another object to minimize the effort required to control a static timing model of a digital transistor circuit.
It is still another object to reuse existing machinery for automatically generating timing models, currently accounting for consistent local information, extending the use of the machinery to account for multiple separate sets of local information which may be mutually inconsistent.
These and other objects, aspects and advantages of the invention are achieved by performing automatic timing model construction several times on certain problem CCCs, with different, typically incompatible sets of user-selected local information for each call. Each of the sets of local information is considered a mode of operation of the circuit, and each generates a timing model for this mode of operation. The resulting set of timing models are placed in parallel in the overall timing graph for the digital design as a whole, which has the effect of making the timing analysis choose the most conservative numbers from across the set of parallel models.
Local information that describes the modes in the invention is not limited to sets of logical constants on control inputs. More particularly, transistor directions, logical constraints on sets of inputs, which selectively ignore transistors during timing model construction and logical constants on non-control inputs are also included.
The timing model created by an analysis of the modes is not limited to fixed delay numbers, but instead includes sensitizations, which are applied to a simulation when timing analysis is run. This allows precise response of the timing analysis to variations in loading, to input waveform shape, to variations in environmental parameters, such as voltage and temperature, and to variations in transistor characteristics such as those due to process drift.
The timing model creates separate timing points for each operating mode of the circuit, which permits separate application of timing-point-specific user controls, such as phase renames, to the timing models of each mode. This last point is explained in more detail in the detailed description of the invention.
The present invention provides a method and a mechanism for performing a static timing analysis of a circuit design, the circuit design comprising interconnected active devices, the method includes the steps of: a) inputting a topology of the active devices interconnections; b) inputting multiple sets of data descriptive of modes of operation of the circuit design, the multiple sets of data including timing related commands; c) for each data set, constructing a corresponding timing model; d) inputting at least one portion of the timing model into a simulator; and e) inputting selected outputs of the simulator to perform timing analysis of said circuit design.
The accompanying drawings, which are incorporated in and which constitute part of the specification, illustrate the presently preferred embodiments of the invention which, together with the general description given above and the detailed description of the preferred embodiments given below serve to explain the principles of the invention.
In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent to those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
Aspects of the present invention advantageously provide a multiple mode approach to build static timing models for digital transistor circuits. One embodiment of the invention will now be described, wherein at the coarsest level, the flow of information through the new program is the same as through the current static transistor timing code. More particularly:
1. The user writes the topology of a transistor level design to a file
2. The user writes a Tcl commands input file
3. The software reads the transistor topology
4. The software reads the Tcl input file and performs the commands (including some new commands).
5. The software uses timing models to perform static timing analysis.
6. The software writes reports.
Among the novel actions are found new commands added in step 2, and their execution in step 4, which includes the multiple calls to the automatic timing model construction and the infrastructure that supports them. In addition, there is a certain infrastructure in both places that enables local information which is intended for one call to the automatic timing model construction to be distinguished from local information which is intended for a separate call.
Referring back to the 2-input NOR gate shown in
Assuming that the user wants the NOR gate to operate in two modes: mode_A off, where A is held low, and mode_A_B_together, where A and B are logically locked to rise and fall together. Then, the user would write the following commands in a Tcl file: (It is a common practice for CAD applications to provide a scripting language, a language where the end user gives a series of commands which control various internal steps using the CAD application. It is common to do this by adding extensions to the Tcl language, where the extensions are specific to the particular CAD application. The example below is a short sequence of such commands, where the commands themselves are extensions to Tcl added to a static timing analysis CAD program. The commands are executed by subroutines within this CAD programs, and this is described in detail below.)
Briefly, the actions of each of these commands are as follows, with additional detail to follow later:
Referring now to
Leaving aside the details of what this specific command does, one notes that if each mode's psegs went directly from the NOR gate's A and B input timing points to its output Z timing point, there would be no way to selectively apply rename_phase to only the mode_A_off or only the mode_A_B_together section of the final timing model for the NOR gate. By adding the internal timing points, the command can, e.g., be applied to the Z_mode_A_off timing point, which affects only the mode_A_off section. Note that this is only one embodiment of the present invention. Internal points can be created at just inputs, just outputs, or in neither place.
The psegs connecting the original timing pins to the internal timing pins, pseg1, pseg2, pseg3, pseg4, pseg8, and pseg9, are a bit unusual. Unlike normal CCC psegs, they do not have sensitizations. Their purpose is purely to allow ATs from the original timing input pins A and B to flow unchanged to the internal timing points A_mode_A_off, A_mode_A_B_together, B_mode_A_off, and B_mode_A_B_together and the ATs from the internal timing points Z_mode_A_off and Z_mode_A_B_together to flow unchanged to the original output pin Z (where they will be jointly ‘worst-cased’). Since the ATs flow unchanged through these psegs, they have delays of exactly 0, hence they do not need any simulation and, hence, they do not need sensitizations. Although they are integral to the final CCC model, they behave like wire psegs, albeit with zero delay, and, hence, they are referred to as “perfect wires”.
In the final timing model, the psegs which do have sensitizations and do have delays are pseg5, pseg6, and pseg7. Pseg6 is created during the execution of the tlt::build_multi_mode_section -suffix _mode_A_off Tcl command and pseg5 and pseg 7 are created during the execution of the tlt::build_multi_mode_section -suffix _mode_A_B_together Tcl command. In fact, during each of these modes, what happens during the execution of the tlt::build_multi_mode_section Tcl command is that
The final sensitizations for pseg6 in
In order to avoid unnecessarily obscuring the present invention the original pin names of the NOR gate CCC have been chosen here to agree with the names of the electrical nets that they are connected to, but this is a simplification of the actual naming convention in use.
The final sensitizations for pseg5 and pseg7 in
In the example of building the multimode timing model example shown in
Each of the 6 Tcl commands,
In the processing of the first command in this example, a tlt::start_multi_mode command, decision block 1010 identifies the command and branches to step 2000 in
In the processing of the second command in this example, a tlt::set_low command, the command is parsed by step 1000 in
In the processing of the third command of the present example, namely, tlt::build_multi_mode_section command, the command is parsed in step 1000 in
Step 3020 builds a timing model for the CCC pointed to by “theCurCCC” as set in step 2010. Here, timing model construction uses the fact that input A is set logically at low as set in step 5030 and, as was the prior practice, builds psegs and sensitizations for the NOR gate CCC consistent therewith. On this call, the timing model constructed by step 3020 contains just a pseg identical to pseg2 in
Steps 3030 through 3060 convert the pseg from B to Z into pseg 6 from B_mode_A_off to Z_mode_A_off in
Step 3070 erases the local information that was used in this build_multi_mode_section so that it does not interfere with the construction of the next section. For this call, it erases the volatile set_low on A, so that this logical constant will be removed from the next model build, in the next call to step 3020. Step 3070 uses the list of volatiles built up in step 5020. It erases all of the local information at all of the locations that are pointed to by the list, then it erases the list itself. Note that the “-volatile” mechanism is not the only possible way to prevent local information in one mode's model build from interfering with the next model build. One alternative is to provide commands for the users to explicitly erase local information after each multi mode section build.
After step 3070 processing returns to step 1000 to process the next Tcl command.
In the processing of the fourth command in this example, a tlt::make_net_group command, the command is parsed by step 1000 in
In the processing of the fifth command in this example, a tlt::build_multi_mode_section command, the command is parsed by step 1000 in
In the processing of the final, sixth, command in this example, a tlt::finish_multi_mode command, the command is parsed by step 1000 in
The present example illustrates the processing of one NOR gate CCC in detail. In a typical run, multimode processing would be called many times on many separate CCCs.
While the present invention has been particularly described in conjunction with a specific preferred embodiment, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art in light of the present description. It is therefore contemplated that the appended claims will embrace any such alternatives, modifications and variations as falling within the true scope and spirit of the present invention.
