Method of associating timing violations with critical structures in an integrated circuit design

[0001] 1. Field of the Invention

[0002] The present invention is directed to application specific integrated circuit (ASIC) designs. More specifically, but without limitation thereto, the present invention is directed to identifying and correcting timing problems in register transfer level (RTL) code for an integrated circuit design.

[0003] 2. Description of the Prior Art

[0004] Previous approaches to correcting design defects in application specific integrated circuit (ASIC) designs require a significant amount of time analyzing the back-end flow, or layout, of the ASIC design. Attempting to resolve design problems at this stage in the design typically increases turnaround time (TAT) and jeopardizes schedule commitments.

[0005] Static timing analysis (STA) and timing closure are used to identify and correct timing violations in an integrated circuit design as quickly as possible to conserve valuable engineering resources and to meet production schedules. Timing violations that are identified in static timing analysis are resolved according to timing closure methods to ensure that the integrated circuit design will work in silicon according to design specifications.

[0006] In exemplary embodiments, a method and computer program product for associating timing violations with critical structures in an integrated circuit design include steps of:

• • [0007] (a) receiving as input an integrated circuit design;
  • [0008] (b) identifying a critical structure in the integrated circuit design; and
  • [0009] (c) generating as output a script for a static timing analysis tool that includes a timing check for a path having a start point at an input of the critical structure and an end point at an output of the critical structure.

[0013] Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some elements in the figures may be exaggerated relative to other elements to point out distinctive features in the illustrated embodiments.

[0014] To simplify referencing in the description of the illustrated embodiments of the present invention, indicia in the figures may be used interchangeably to identify both the signals that are communicated between the elements and the connections that carry the signals. For example, an address communicated on an address bus may be referenced by the same number used to identify the address bus.

[0015] Previous methods of resolving timing violations lack an efficient and organized procedure to analyze all timing violations reported by a static timing analysis tool, to determine the root causes of the timing violations, and to converge on a solution that resolves the timing violations. Timing problems encountered during static timing analysis may be induced by architectural and structural attributes of the integrated circuit design at the highest level of the design in the register transfer level code, that is, the integrated circuit design may include a logical implementation that is not realistic from a performance standpoint. For example, if the design reads data from a memory and performs operations on the data with logic gates such as exclusive-OR and so on before the data is registered by sampling the data in a flip-flop, and if the target clock frequency is too high, then the logical implementation is unrealistic in terms of performance, and timing closure of the design may not be possible after cell placement and routing. Other timing violations may be induced by inefficiencies in netlist synthesis, a sub-optimal floorplan, and/or poor placement and routing.

[0016] An analysis of an individual path that includes a timing violation may require that the circuit designer check a schematic to find the source of the timing violation. However, the overall timing scheme is frequently difficult to visualize when individual endpoints, that is, the primary outputs of the design, are the entire focus of the design. Additionally, the more timing violations reported by the static timing analysis, the more difficult the timing closure will be. For example, in a static timing analysis of an integrated circuit design containing one million gates, there may be tens of thousands of timing violations reported, and it is the responsibility of the circuit designer to trace through the timing reports and circuit schematics to determine which blocks and cells caused the timing violations. Even then, the root cause of the timing violations, that is, the architectural or structural cause, may be overlooked, in which case each individual path is typically manually examined with a schematic browser, consuming valuable schedule time and resources. This trial-and-error approach is extremely time consuming at best, and is not always successful. As a result, a significant amount of development resources must be assigned to static timing analysis and timing closure while at the same time assuming a high risk of failure to meet a design schedule.

[0017] Design engineers who perform static timing analysis generally rely on the various negative slack timing reports generated by a static timing analysis tool, checking each timing report to develop a plan to close timing for each timing violation identified. A preferable approach from the design time cost standpoint would be to categorize the timing violations into structure types and to proactively check timing of paths in the register transfer level code that include structures that may potentially be a source of timing problems. Examples of structure types in register transfer level code that are potential sources of timing problems include memory interfaces (I/F), coreware interfaces, input/output (I/O) interfaces, fan-in logic cones, fan-out logic cones, large multiplexers, and high fanout nets. By categorizing timing violations into structure types, the cycle of finding a solution to one timing problem that often introduces another timing problem may be advantageously avoided.

[0018] The embodiments described below provide a method of identifying structure types in register transfer level code in a script for a static timing analysis tool to determine whether any of the identified structures or architectural attributes account for any of the negative timing slack problems encountered during static timing analysis. Additionally, a report is generated from the static timing analysis that categorizes the timing violations to the extent made possible by various statistics. The categorized information may be used to assist the circuit designer in visualizing the timing problems so that a well-structured and efficient plan for timing closure may be developed.

[0019] Categorizing timing violations based on the structural and architectural attributes in the register transfer level code of a circuit design is an extremely powerful tool for visualizing the timing problems that have to be resolved in timing closure and for developing an effectively organized and prioritized plan for achieving timing closure. For example, depending on the magnitude and number of timing issues, architectural and/or register transfer level code modifications may have to be made, a modification to netlist synthesis may have to be made, an alternative floorplan may have to be implemented, and a different approach to placement and routing may have to be made to shift physical resources to the more timing critical areas of the integrated circuit design.

[0020] In one embodiment, a method of associating timing violations with critical structures in an integrated circuit design includes steps of:

• • [0021] (a) receiving as input an integrated circuit design;
  • [0022] (b) identifying a critical structure in the integrated circuit design; and
  • [0023] (c) generating a script for a static timing analysis tool to check timing of a path in the integrated circuit design having a start point at an input of the critical structure and an end point at an output of the critical structure.

[0024] FIG. 1 illustrates a flow chart 100 for a method of associating timing violations with critical structures in an integrated circuit design.

[0025] Step 102 is the entry point of the flow chart 100.

[0026] In step 104, an integrated circuit design is received as input. The integrated circuit design may be, for example, the register transfer level code or a netlist for an application specific integrated circuit (ASIC) design or any other type of circuit design that may be expressed in register transfer level code.

[0027] In step 106, critical structures and architectural attributes are identified from the integrated circuit design, for example, by a register transfer level code analysis tool according to a set of design rules. A critical structure or architectural attribute is defined as a structure or design feature that is likely to result in a timing violation during netlist synthesis, cell placement and routing, or timing closure. Specifically, a critical structure is defined as a structure or design feature that violates an integrated circuit design rule.

[0028] A register transfer level code analysis tool incorporating circuit design rules for the integrated circuit design may be selected, for example, from a library of RTL analysis tools for a variety of ASIC vendors. The vendor may be determined, for example, by an identifier in the RTL code or from a setup file. The RTL analysis tool reads the RTL code, for example, in Verilog format or Verilog Hardware Description Language (VHDL) format and performs a design check on the RTL code according to a set of design rules that include, for example, structural rule checking and timing related rule checking. Examples of design rules that may be implemented in the RTL analysis tool according to well known computer techniques include, but are not limited to, the following:

Rule: Critical Paths

[0029] The critical paths rule identifies, for example, the paths for which the maximum allowed time required by the performance specifications minus the calculated path time is less than zero, that is, negative slack. Negative slack may be caused, for example, by large structures in the critical path. Potentially problematic non-critical structures are also identified having a slack that is less than five percent of the nominal clock rate.

Rule: Large Structures

[0030] The large structures rule identifies, for example, large multiplexers in the circuit design having an input bus width exceeding a selected threshold. A default value for the bus width threshold may be, for example, 64. If there is a 2:1 multiplexer having an input bus width greater than 64, this would be reported as a critical structure. Large multiplexers may result in a design problem during layout.

Rule: High Fan-out Nets

[0031] The high fan-out nets rule identifies as critical any paths that include nets that have a fan-out exceeding a selected threshold value specific to the circuit design.

Rule: Logical Cone (Fan-in)

[0032] The Logical cone (fan-in) rule identifies as critical structures flip-flops in the RTL code having a fan-in of more than, for example, 500 starting points.

[0033] Because each register is considered as a function of its inputs, a large number of starting points requires a large number of input vectors to verify the testability of the circuit design. Also, there will be a large amount of logic connected to the register at the end point, which may result in high congestion and extra buffering to compensate for non-ideal placement. Further, a large logical cone fan-in may result in timing closure problems if the starting points are all near the critical path limit, because the delay of one logic path may not be shortened without increasing the delay of another.

Rule: Logical Cone (Fan-out)

[0034] The Logical cone (fan-out) rule reports as critical structures any flip-flops in the RTL code having a fan-out of more than, for example, 500 ending points.

[0035] A large number of ending points increases the difficulty of verifying the testability of the circuit design. Also, there will be a large amount of logic connected to the register at the starting point, which may result in high congestion and extra buffering to compensate for non-ideal placement. Further, a large logical cone fan-out may result in timing closure problems if the ending points are all near the critical path limit, because the delay of one logic path may not be shortened without increasing the delay of another.

Rule: Large Arithmetic Operators

[0036] The large arithmetic operators rule identifies as critical structures any arithmetic structures such as adders, subtractors, multipliers, bitwise AND, bitwise OR, and OR/XOR trees having a number of inputs exceeding a selected threshold, for example, 64. The number of inputs is calculated by multiplying the number of input channels times the bit width of each channel.

[0037] In step 108, a script is generated for a static timing analysis tool according to well known computer programming techniques to check the timing of the critical structures and architectural attributes identified in the integrated circuit design. For example, if a multiplexer is identified as a critical structure during the register transfer level code analysis, then the following script may be generated for a static timing analysis tool:
Check timing:<Start point>TO<End point>
where the start point is an input of the multiplexer and the end point is the output of the multiplexer.

[0038] In step 110, the script generated for the critical structures in step 108 is executed by a static timing analysis tool after the master script for the entire circuit design has been run to detect timing violations associated with the critical structures and architectural attributes identified in the integrated circuit design. In the example of the critical multiplexer above, any negative slack paths involving the start points and end points surrounding the multiplexing structure will be reported in the static timing analysis. Also, potentially problematic end points may be identified in the register transfer level code and cross-referenced to negative slack end points found in the static timing analysis. Accordingly, whenever there is a negative timing slack for any timing path that includes a critical structure or end point identified in the register transfer level code from the register transfer code analysis, then a timing violation report will be generated for each instance. The following examples of additional information and statistics may also be generated:

• • [0039] (1) the source of the timing violation as it relates to the register transfer level code associated with each timing violation reported by the static timing analysis; and
  • [0040] (2) the total number of paths in the register transfer level code having negative slack and a breakdown of the paths according to category of structure or architectural attribute as a percentage of the total, for example, a register transfer level code analysis script executed by a static timing analysis tool might generate the following category breakdown illustrated in Table 1:

[0041]

	TABLE 1
	large fan-in logic cones:	256	(5%)
	large fanout logic cones:	12,353	(25%)
	memory/coreware I/F paths:	1,444	(15%)
	input/output I/F paths:	852	(9%)
	large multiplex structures:	8,456	(33%)
	structural bottlenecks:	856	(10%)
	large register arrays:	86	(1%)
	large arithmetic structures:	88	(1%)

[0042] The category breakdown of Table 1 may provide insight in to the overall timing issues to assist the circuit designer in the development of an effectively organized and structured plan to achieve timing closure.

[0043] In step 112, a recommended strategy is generated for modifying the circuit design to correct each of the timing violations detected by the static timing analysis associated with the category of the design rule violation from the register transfer code analysis. For example, large sequential arithmetic elements may be partitioned into smaller parallel arithmetic elements to reduce the delay; large centralized multiplexer structures may be partitioned into smaller local multiplexer structures; and so on.

[0044] Step 114 is the exit point of the flow chart 100.

[0045] The steps described above with regard to the flow chart 100 may also be implemented by instructions performed on a computer according to well-known programming techniques.

[0046] In another embodiment, a computer program product includes a medium for embodying a computer program for input to a computer and a computer program embodied in the medium for causing the computer to perform steps of:

• • [0047] (a) receiving as input an integrated circuit design;
  • [0048] (b) identifying a critical structure in the integrated circuit design; and
  • [0049] (c) generating as output a script for a static timing analysis tool that includes a timing check for a path having a start point at an input of the critical structure and an end point at an output of the critical structure.

[0050] FIG. 2 illustrates a flow chart 200 of a computer program product for associating timing violations with critical structures in an integrated circuit design from the method of FIG. 1.

[0051] Step 202 is the entry point of the flow chart 200.

[0052] In step 204, an integrated circuit design is received as input.

[0053] In step 206, at least one critical structure or architectural attribute is identified in the integrated circuit design, for example, by analyzing the register transfer level code according to a selected set of design rules. As explained above, a critical structure is defined as a structure or design feature that violates an integrated circuit design rule.

[0054] In step 208, a script for a static timing analysis tool is generated as output that includes a timing check for a path having a start point at an input of the critical structure and an end point at an output of the critical structure. Steps 206 and 208 may be repeated to identify all the critical structures in the integrated circuit design and to include a timing check for each critical structure in the script for the static timing analysis tool. Any timing violations detected by the static timing analysis tool from the script may then be associated with the corresponding critical structure so that the efforts made to correct the integrated circuit design may be properly directed to avoid generating additional timing violations.

[0055] Step 210 is the exit point of the flow chart 200.

[0056] Although the methods illustrated by the flowchart descriptions above are described and shown with reference to specific steps performed in a specific order, these steps may be combined, sub-divided, or reordered without departing from the scope of the claims. Unless specifically indicated herein, the order and grouping of steps is not a limitation.

[0057] The method of associating a timing violation with a critical structure in an integrated circuit design described above pro-actively drives the static timing analysis to achieve timing closure more efficiently than methods that do not associate timing violations with specific structures in the register transfer level code.

[0058] The specific embodiments and applications thereof described above are for illustrative purposes only and do not preclude modifications and variations that may be made thereto by those skilled in the art within the scope of the following claims.