1. Field of the Invention
The present invention relates to static timing analysis, and in particular to parallel parasitic processing used during static timing analysis or distributed static timing analysis.
2. Related Art
FIG. 1 shows a simplified representation of an exemplary digital ASIC design flow. At a high level, the process starts with the product idea (step 100) and is realized in an EDA software design process (step 110). When the design is finalized, it can be taped-out (event 140). After tape out, the fabrication process (step 150) and packaging and assembly processes (step 160) occur resulting, ultimately, in finished chips (result 170).
The EDA software design process (step 110) is actually composed of a number of steps 112-130, shown in linear fashion for simplicity. In an actual ASIC design process, the particular design might have to go back through steps until certain tests are passed. Similarly, in any actual design process, these steps may occur in different orders and combinations. This description is therefore provided by way of context and general explanation rather than as a specific, or recommended, design flow for a particular ASIC.
A brief description of the components steps of the EDA software design process (step 110) will now be provided:
System design (step 112): The designers describe the functionality that they want to implement, they can perform what-if planning to refine functionality, check costs, etc. Hardware-software architecture partitioning can occur at this stage. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Model Architect, Saber, System Studio, and DesignWare® products.
Logic design and functional verification (step 114): At this stage, the VHDL or Verilog code for modules in the system is written and the design is checked for functional accuracy. More specifically, the design is checked to ensure that it produces the correct outputs. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include VCS, VERA, DesignWare®, Magellan, Formality, ESP and LEDA products.
Synthesis and design for test (step 116): Here, the VHDL/Verilog is translated to a netlist. The netlist can be optimized for the target technology. Additionally, the design and implementation of tests to permit checking of the finished chip occurs. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Design Compiler®, Power Compiler, Tetramax, and DesignWare® products.
Netlist verification (step 118): At this step, the netlist is checked for compliance with timing constraints and for correspondence with the VHDL/Verilog source code. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Formality, PrimeTime, and VCS products.
Design planning (step 120): Here, an overall floorplan for the chip is constructed and analyzed for timing and top-level routing. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Astro, Nanotime, and IC Compiler products.
Physical implementation (step 122): The placement (positioning of circuit elements) and routing (connection of the same) occurs at this step. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include the Astro and IC Compiler products.
Analysis and extraction (step 124): At this step, the circuit function is verified at a transistor level, this in turn permits what-if refinement. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include AstroRail, PrimeRail, Primetime, and Star RC/XT products.
Physical verification (step 126): At this step various checking functions are performed to ensure correctness for: manufacturing, electrical issues, lithographic issues, and circuitry. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include the Hercules product.
Resolution enhancement (step 128): This step involves geometric manipulations of the layout to improve manufacturability of the design. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Proteus, ProteusAF, and PSMGen products.
Mask data preparation (step 130): This step provides the “tape-out” data for production of masks for lithographic use to produce finished chips. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include the CATS® family of products.
Referring back to netlist verification (step 118), 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 consequential 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.
FIG. 2 illustrates a conventional static timing (STA) technique including setup 210 and timing analysis 211. During setup 210, step 201 can load an integrated circuit (IC) design. In one embodiment, the design can be in the form of a gate-level netlist. At this point, the IC design can be linked to, i.e. mapped to, one or more cell libraries at the desired technology node.
Step 202 can back-annotate the interconnect parasitics of the design onto the IC design using the netlist. Parasitics can include the capacitance from a conductor to ground, the capacitance between conductors, and bulk resistance. In one embodiment, the parasitics of the design can be stored in a set of IEEE Standard Parasitic Exchange Format (SPEF) files. Step 203 can load any timing constraints and exceptions to be applied to the design.
During timing analysis 211, step 204 can perform a timing update for the design using the parasitics, timing constraints, and exceptions. In general, this timing update can include building a timing graph corresponding to the gate level netlist based on the timing constraints and exceptions. This timing graph can be finalized, i.e. the vertices of the graph are given level numbers so that standard algorithms, e.g. a breadth first search that starts at a root node and explores all neighboring nodes, can then be applied on the timing graph. In one embodiment, techniques can be applied to break any loops that might occur in the timing graph. Then, any constants from the timing constraints or from the netlist can be propagated in the timing graph. Using the finalized timing graph, delays, slews, and slacks can be calculated and propagated. At this point, timing analysis can be performed and one or more reports can be output in step 205.
Conventionally, setup 210 has generally been performed before timing analysis 211. Specifically, an STA tool progresses through each of steps 201-205 in order and proceeds to the following step only after the previous step has been completed. Of these steps, back-annotating interconnect parasitics (step 202) is often the largest portion of the analysis setup runtime, e.g. approximately 50% of the setup time and 10-15% of the total runtime. Therefore, a need arises for improving performance of STA.
To improve STA efficiency, an STA tool can manage multiple runs having different parameters and automatically merge the results of these runs. Parameters can include, but are not limited to, modes (e.g. test mode, normal operation mode, power-down mode, etc.) and corners (e.g. process parameters including minimum and maximum temperature, minimum and maximum voltage, etc.). This type of STA is called distributed static timing analysis (DSTA) and is described in further detail in U.S. Pat. No. 7,739,098, issued on Jun. 15, 2010, and entitled, “SYSTEM AND METHOD FOR PROVIDING DISTRIBUTED STATIC TIMING ANALYSIS WITH MERGERED RESULTS”. In one embodiment of DSTA, a master STA process (master) can initiate and coordinate the multiple runs performed by slave STA processes (slaves), and merge the results of the slaves. In such an embodiment, the master can partition the netlist and dispatch data to the slaves. Specifically, in DSTA, the operations 201, 202, 203 are done sequentially at the master and the operations 204, 205 are done in parallel at the slaves.
In general, in DSTA, the master consumes memory to hold the parasitic data for timing or signal integrity analysis, so as to facilitate partitioning and dispatching the parasitic data to the slaves. Therefore, a need arises for improving performance and memory of the DSTA master. Specifically, a need arises for dealing with the increase of time associated with setup in STA as well as reducing the memory requirements for DSTA.