It's difficult to even imagine that point in our history when designers managing circuit timing used calculators and spreadsheets. Or, after the advent of event-driven timing simulation, when we searched through endless reams of timing diagrams, hoping our new set of simulation vectors would uncover that last hidden bug. Today, static timing analysis tools have matured to the point of handling significantly more complex design styles and have become mandatory for handling the largest designs in the shortest time.

Static timing tools are exhaustive - all timing paths are analyzed for errors, without the need for simulation vectors. They are capable of handling multi-million gate designs and can analyze the design several orders of magnitude faster than timing simulation. Static timing tools are also the perfect complement to logic synthesis, both of which assume synchronous logic behavior.

In fact, static timing analysis technology is now becoming pervasive across the entire design flow. It has become embedded alongside nearly every major design transformation algorithm, as the primary means for optimizing toward timing sensitive design goals. As a result, it is now more difficult to determine qualifying candidates for this month's Focus Report. Even more confusing are the different flavors of timing analysis products available in the marketplace today.

This article examines the different kinds of timing analysis products used in ASIC, FPGA, and board-level design. We will explain how the technology works, how it differs from dynamic simulation, and summarize the methodologies used in practical flows. We will also explore the variety of timing checks performed, frequently used terminology, special features, and some practical limitations to the tools. Finally, we will discuss emerging challenges in the area of timing analysis.

An introduction, please

Most of the products featured in this report rely on static timing analysis technology, which differs from dynamic simulation in several fundamental ways. First, static tools don't have a simulation cycle and therefore don't schedule events. Instead, static tools sum up and compare delays through paths, relative to pre-defined clocks. Rather than evaluate logic function, static tools focus solely on timing relationships. Once a static tool has enumerated all logically consistent paths, it works in spreadsheet-like fashion to locate negative slack errors without the need for vectors to activate a path. By contrast, dynamic timing simulation can't find violations unless a sequence of vectors highlights that specific case. Furthermore, static timing tools automatically guide the user to the most critical problems first.

Static timing tools can identify an even wider variety of timing errors than simulation: setup/hold and recovery/removal checks (including negative set up/hold); minimum, maximum transition; clock pulse width and clock skew errors ; glitch detection on gated clocks; bus contention and bus float errors; and unconstrained logic paths. In addition, some static timing tools compute delays across pass transistors, transfer gates, and transparent latches. They automatically identify and sort critical paths, constraint violations, asynchronous clock domains, and bottleneck logic.

There are a number of variations in timing analysis tools. Some products, such as Primetime from Synopsys (Mountain View, CA) and SST Velocity from Mentor Graphics (Wilsonville, OR), target full-chip IC design.

On-chip PVT (process, voltage, temperature) variations, transistor-level analysis, and negative setup/hold checks are important at this level. Innoveda's (Marlboro, MA) Blast, for example, focuses on FPGA and board-level design, with support for single and multi-board configurations, links with board-level crosstalk analysis, and imported models from Chronology's (Redmond, WA) Timing Designer Pro. Envisia from Cadence (San Jose) and Blast Chip from Magma (Cupertino, CA) provide full-chip timing analysis features tightly bundled with synthesis and layout technology; neither have yet announced stand-alone timing analysis products, but emphasize robust static timing analysis functionality. Circuit Semantics (San Jose) offers mixed-level timing analysis targeting advanced CMOS design styles, including domino and self timed logic. Ultima's (Sunnyvale, CA) Millennium and Silicon Metrics' (Austin, TX) Siliconsmart TSO are complementary technologies focused on improved accuracy for chip level static timing tools.

Timing Designer Pro from Chronology and Waveformer Pro from Synapticad (Blacksburg, VA) are graphical waveform editors with embedded static timing engines, particularly useful for interactive modeling and analysis.

A look under the hood

Static timing tools begin by accepting user inputs, parsing the design netlist, and mapping the cells into a target library. From this netlist, a list of all paths is created and then pruned based upon various criteria. Each path contains a starting point and an ending point, consisting of either a memory element or a primary I/O pin. (Note that transparent latches may be treated either as a gate or a start/end point.)

Next, the delay engine computes values for the cells and interconnects, incorporating SDF timing data or SPEF parasitic data for post-layout accuracy, or using statistical wire-load models for pre-layout estimation. Parasitic data may either be detailed or reduced-form RC trees (SPEF, DSPF, RSPF file formats). The timing verifier engine then calculates slack and constraint violations, relative to pre-defined clock domains. Reports and various visualization tools can then provide results sorted according to user preferences.

Modern static timing tools support the rich variety of features needed to support today's complex designs. First and foremost is support for unlimited, complex clock domains. Multiple frequencies, phases, and waveform shapes will often characterize these clocks.

Furthermore, since gated clocks are a standard technique in low-power design, it's crucial to properly time waveform edges and ensure that clock gating doesn't create corrupted edges. Asynchronous clocks (clocks with no definable relationship to one another) are a particular challenge. SST Velocity, for example, can automatically identify asynchronous clock domains and eliminate the false paths so that the remaining synchronous logic can be properly analyzed.

Some digital designs include multi-cycle paths, in which intermediate combinational logic spans several clocks. Multi-cycle paths must be specified to the tool, or else an error must be assumed. Similarly, zero-cycle paths define potential race conditions between two state devices; if a zero-cycle path is intentional, it must be specified to avoid a hold violation. All static timing tools also support reconvergent fanout, which ensures that only realistic combinations of min/max delays propagate for proper slack analysis. The mode analysis feature allows the user to specify constant values on ports or pins, in effect constraining the analysis to specific modes of operation. This becomes extremely useful to isolate troublesome areas in full-chip analysis, or to verify timing passing through test logic.

Some timing analysis tools enable tester compliance checking, so that device tester constraints are properly factored into the analysis criteria. Combinatorial loops must be broken so that the path is traversed only once in calculating the delay. On-chip PVT variations and correlated min/max analyses are becoming more important for chip-level sign off. These techniques allow the user to specify derating factors or percentages for worst-case analysis that account for changing environmental conditions affecting transistor slew rates.

Putting timing analysis tools to work

So, how can we take full advantage of all of these features when working in real design flows? The exact usage methodology will vary depending upon the class of design, the category of tool used, and many other variations. However, we can outline a generalized methodology applicable in typical flows.

The user must specify the target library to be used, input netlist, and design/block-level timing assertions and exceptions. Timing constraints are generally the same as those used for logic synthesis, although additional assertions can be added. For designs containing true asynchronous logic to be isolated and verified using gate-level timing simulation, having a design partitioning strategy amenable for verification is advised.

Next, timing shell models for complex cells (such as microprocessors, memories, analog blocks, and custom logic) must be created. These models are often manually created from data sheet specifications or other forms of analysis. Timing shell models can also be automatically extracted for pre-verified synchronous design blocks. Some static timing tools create their own, or import formats used during interactive waveform modeling.

For pre-layout timing, statistical wire-load models can be used and should correlate with those used for synthesis. Post-layout analysis will use back-annotated data. Traditional back annotation uses SDF timing files (one for each PVT variation).

Alternately, parasitic RC data can sometimes be directly imported such that timing delays can be calculated with internal delay engines. Some tools now support DCL and/or OLA, permitting more exact correlation with ASIC foundry process parameters (see sidebar). DCL and/or OLA have been designed to work together with back-annotated RC data for optimal accuracy. When importing RC data rather than SDF files, only a single file is required to support all PVT variations. This becomes a substantial cycle time benefit with multi-GB SDF files.

Many clock domains can be automatically identified, however. The user must specify each clock's frequency, phase, and waveform shape. Derived clocks must also be specified as part of setup. SST Velocity can automatically identify asynchronous clock domains and signals crossing through the resulting asynchronous logic. In other cases, such signals must be identified as false paths, along with any other logically impossible paths, for elimination from analysis. While there is no hard limit to the number of clock domains in a design, realize that each must be specified with a defined harmonic relationship to another existing clock. In general, the effort required to properly specify these clock domains during setup will be returned many times over in faster and more thorough analyses.

The user typically begins timing analysis following synthesis. (However, note that static timing technology is embedded within all synthesis and timing driven placement floorplanning tools.) Users will generally choose nominal mode analysis while iterating through the synthesis and early layout process, then switch to more thorough best/worst-case analysis after layout. Thus, the tool should support single-pass analysis of best/worst case conditions in order to minimize cycle time. Timing analysis generally begins at the block level, and aggregates upward to the full design (whether the design is a single integrated circuit or multiple system boards).

Some data flow paths within the design will undoubtedly require special attention. This can be accomplished using mode analysis to avoid analyzing uninteresting paths. Generally, built-in self-test logic should be disabled during this time. In some cases, data flow through selected blocks can't be analyzed using synchronous techniques and will require dynamic timing simulation. If properly isolated, these can be handled well within simulation capacity limits. The resulting timing can then be used to create a timing shell forintegration back into higher level static analysis.

A variety of outputs can be used to diagnose the design. Timing slack reports can quickly identify trouble areas and generally permit automatic generation of schematics containing only the affected logic. Constraint violations are another class of output, which can report on clock skews, multi-cycle paths, and so on. Bottleneck analysis can identify logic common to many violating paths, guiding the designer to top priority cell modifications.

The methodology for waveform modeling tools with embedded timing analysis varies in several ways. Generally, users are less reliant on synthesis output at this stage and are manually specifying timing relationships for the design, a specific block, or complex core. Often, users select critical paths of their circuit for waveform modeling rather than exhaustive coverage of every circuit node in the design. In this way, these tools help the user define requirements and legal constraints on the design, and then export the results to other static timing tools for exhaustive analysis.

Other tools, such as Millennium, Siliconsmart TSO, or Celtic (Cadmos, San Jose), are complementary tools that further leverage static timing analysis. Millennium accepts detailed RC data, computing delays for tens of millions of RC elements in several hours, within five percent of SPICE accuracy. The tool performs advanced signal-slope modeling of frequency-dependent effects, full-chip clock skew analysis with graphical viewing capability, accurate analysis of buses and parallel/tri-state drivers, and automatic Spice deck generation for critical paths. It processes interconnect topologies including 2-D and 3-D meshes, is fully hierarchical, as well as incremental for ECO support. The tool then outputs SDF and Synopsys design constraint files for downstream static timing analysis.

Siliconsmart TSO is a collection of specialized model compilers that leverage the emerging OLA standard to enable transistor-level accuracy for gate-level static timing analysis tools. Siliconsmart TSO generates dynamic, instance-specific operating point path delay models for an entire circuit, then links them into timing-analysis tools using the OLA modeling interface. These path-delay models address the growing nonlinear and complex interdependence between cell and interconnect modeling. It eliminates the need for SDF files, and is capable of compressing parasitic data up to several orders of magnitude without loss in accuracy. The tool can remove the 15 to 25 percent pessimism in slew rate delays typically found in static models, and account for the timing impact of IR drop and temperature variation.

Celtic focuses on post layout, cross coupling noise effects that can impact actual timing delays by as much as 100 percent. The tool accepts a cell-level netlist, coupled RC parasitics, a characterized noise library, and specification of signal timing windows and signal transitions (which can be imported from static timing analyzers). Celtic uses this information to produce a sorted report of peak noise on victim nets, and creates noise-adjusted SDF data that can be read back into static-timing tools.

More bells and whistles

Depending on your specific design needs, you may want to look out for some special features in static timing tools. As described earlier, automatic identification of asynchronous clock domains and asynchronous path removal can provide a substantial productivity benefit. Similarly, look for tools that support automatic detection and analysis of divided clocks, merged clocks, gated clocks, and transparent latches. If you are incorporating complex cores and need to perform full-chip analysis, core-modeling features will be important. Black box timing models for cores and memories can be created using the Stamp modeling format (part of Synopsys' Tap-In licensing program), or using imported models directly from waveform modeling tools such as Timing Designer Pro. Very large designs can benefit from automatic black box timing model extraction, which creates an external view for a previously analyzed design block.

Designers of high-performance applications should look for slew-dependent slew calculation, in which slew rates are propagated as a function of other input slews. "What if" analysis is a feature which allows the designer to rapidly explore on-the-fly variations, such as altering clock frequencies and duty cycles, changing net or cell delays, or making instance-specific model swaps. If your design has pass gates, pre-charge elements, or other forms of non-static CMOS logic, you should look for integrated transistor-level analysis features. This includes gate inferencing, false-path elimination, correct clock propagation, and grouping of channel-connected transistors.

Designers should also seek out several additional architectural features in static timing tools. A fast incremental capability can speed up full-chip runtimes following minor design changes from hours down to seconds. For designs exceeding ten million gates, look for tools that offer native 64-bit versions. Some tools internally support a node-based architecture for managing timing data instead of a path-oriented data structure. While path architectures scale exponentially with design size, node-based architectures scale almost linearly. Furthermore, incremental and what-if capabilities are greatly enhanced since far fewer re-calculations are typically required in a node-based data structure.

Most of the products in the Focus Table also use visualization to ease interpretation of the data. These can include stacked bar charts, selected path schematic generation, waveform diagram generation, and 2-D thermal graphs to highlight problem areas. Finally, look for increasing support of OLA and DCL library interfaces and support from ASIC suppliers to become increasingly important for reducing cycle times and maintaining correlation accuracy with advanced fab processes.

Emerging challenges

As semiconductor fab processes continue to shrink and adapt to the ever-demanding world of particle physics, timing analysis tools must also adapt. At 150 nanometers and below, crosstalk noise coupling plays an unavoidable part of the delay equation. Unfortunately, actual delay impact due to crosstalk is a fundamentally dynamic phenomenon, involving time transition windows, slew rates, and directional effects.

In addition to capacitive coupling, inductive coupling must also be considered as nets are crowded closer together. This will require incremental inductive extraction capabilities, new filtering and pruning algorithms, and techniques to manage the volume of increased parasitic data. Another emerging trend is Silicon on Insulator (SOI), an alternative fabrication process intended to enable even higher performance designs. However, SOI has several tricky side effects, including a memory effect in which transition delays are a function of previous transitions. Other challenges include automatic partitioning of huge (greater than 20-million gate) designs across multiprocessor configurations to reduce iteration times, and further integration with formal verification technology.

Stephen E. Schulz is a senior member of the technical staff at Texas Instrument Inc.'s Worldwide ASIC division in Dallas. He serves on the board of directors of VHDL International and is the executive sponsor of the System-Level Design Language.

To voice an opinion on this or any other article in Integrated System Design, please e-mail your comments to sdean@cmp.com.