1. Field of the Invention
The present invention relates to static timing analysis and in particular to distributed static timing analysis with merged results.
2. Description of the Related Art
Ignoring timing violations during design implementation can result in designs that fail to meet performance specifications or even fail in silicon. Given tight market windows and multi-million dollar re-spin costs, these design failures can be financially devastating to semiconductor companies. Therefore, design engineers are increasingly demanding techniques to identify timing violations in a design. One such technique, called static timing analysis, attempts to exhaustively analyze all critical paths of a design.
A limited number of static timing analysis (STA) runs, e.g. to provide a minimum time analysis and a maximum time analysis, can be sufficient for large process geometries and/or simple designs. FIG. 1A illustrates an exemplary run 100 in which an STA tool 102 receives a design (e.g. a gate-level description) and an STA set-up 101. STA tool 102 performs the static timing analysis and generates results 103 indicating any timing violations as well as coverage of the static timing analysis. At this point, a user could review results 103 and then attempt to fix the conditions that could be causing the timing violations, if present.
Unfortunately, with process geometries reaching 130 nm and below, gate counts exceeding 30 million, and designs growing in logic and core complexity, identifying timing violations with standard static timing analysis is rapidly becoming one of the most challenging problems for design engineers. Specifically, multiple runs of static timing analysis are typically required to take into account different modes (e.g. test mode, normal operation mode, power-down mode, etc.) as well as corners (e.g. process parameters including minimum and maximum temperature, minimum and maximum voltage, etc.).
FIG. 1B illustrates a flow wherein a user (e.g. a design engineer) 112 uses a design and a generic STA set-up 110 as well as potential set-ups 111 (indicating specific modes and corners available to user 112) to perform multiple runs 10A, 100B, and 100C. For example, in run 10A, STA tool 102A receives a design and an STA set-up 101A that indicates a specific mode and corner for analysis. STA tool 102A performs the static timing analysis and generates results 103A indicating any violating paths as well as coverage of the static timing analysis using that specific mode and corner. In run 100B, STA tool 102B considers design and STA set-up 101B (same design, but different mode and/or corner) to generate results 103B. Similarly, in run 100C, STA tool 102C considers design and STA set-up 101C (same design, but different mode and/or corner than those indicated in design and STA set-ups 101A and 101B) to generate results 103C. Note that STA tools 102A-102C are running independently. That is, STA tools 102A-102C could be running on the same computer or on different computers and could be running at the same time or at different times.
As STA tools 102A-102C complete their analysis, user 112 can review the results of the static timing analysis and perform debugging 113, as necessary, to mitigate timing violations. Of importance, user 112 must manually perform this user analysis/debugging 113 on results 103A-103C. Unfortunately, results 103A-103C typically form large, complex files in which each critical path in the design must be individually extracted for path profiling. Moreover, performing a comprehensive static timing analysis using available modes and corners can take many runs, e.g. 100-200 runs. Therefore, managing and/or merging the results from these runs can be very complex and time consuming.
Therefore, a need arises for a system and method of efficiently managing multiple static timing analysis runs using multiple modes/corners.