Design Feature: August 1, 1996

In the 1980s, most engineers lacked sophisticated timing-analysis tools. In those days, the best most of us could hope for was a four-function calculator and a sharp pencil. To calculate the delays through a circuit, you used a design-rule book that provided the minimum:typical:maximum (m:t:x) de-lays through each gate and the estimated loading and track delays for that gate. (One load equals x nsec, two loads equal y nsec, and so forth.) Now, you have the options of static- and dynamic-timing-analysis tools.

Static-timing analysis is conceptually quite simple: It automates the addition of all the gate and track delays. Consider a simple block of combinatorial logic: A user provides the analyzer with a gate-level netlist, and the analyzer then determines all possible paths from the circuit's primary inputs to its outputs. The analyzer accesses a database containing the m:t:x delays for each gate, along with a rule base describing the estimated loading effects, and ultimately reports the total m:t:x delays for each input-to-output path (Figure 1).

In the past, timing-analysis packages required you to enter the netlist manually. This situation was the case with the first timing-analysis package I ever used (a static-timing analyzer that the group I was in had created). In addition, the model-timing database was a set of simple ASCII text files, one for each model. For example, in the case of an SN7400 quad two-input TTL NAND gate, you might have a text file called "sn7400.del" (Figure 2). When the timing analyzer found a reference to an SN7400 in the netlist, the analyzer would open the corresponding text file to access the SN7400's delays and so on for all of the other devices in the netlist. The contents of a delay file, which the user specified, were presented in the form of a matrix. The analyzer then simply read the inputs on the left until it found the input of interest and then scanned the row to find the delays in the appropriate output column.

Modern static-timing analyzers behave in an almost identical manner, except that they usually provide more detailed timing information for the devices, including separate delays for each input to each output for both rising and falling transitions at the outputs. Also, modern analyzers typically maintain the timing data in a compiled form, and the timing models contain a minimal amount of functional knowledge about their devices, such as any inversions between the inputs and outputs.

Static-timing analysis is well-suited to classical synchronous design, such as pipelined processor architectures, in which registers partition chunks of combinatorial logic (Figure 3). In this case, the main information that the user provides to the analyzer comprises the netlist and details about the clock, including its period or frequency and, possibly, mark/space ratio. The analyzer understands the concept of registers, and the models for the register devices contain details of their setup-and-hold times. Thus, the analyzer calculates the delays through each block of combinatorial logic and simultaneously determines whether these delays violate the setup-and-hold times of the registers associated with that block.

The main advantages of static-timing analysis are its relatively high speed, lack of a requirement for a test waveform, and ability to exhaustively test every possible path into the ground. However, this form of analysis does not check the functionality of the design, so if you mistakenly use an AND gate when you intended to use a NAND, then the analyzer doesn't know or care and simply tells you whether the delays meet your requirements. This situation means that you must combine static-timing analysis with functional verification, such as simulation. Static-timing analysis, thus, goes hand in hand with cycle-based simulation, which, by some strange quirk of fate, is great at checking the functionality of a design but rubbish at verifying its timing (Reference 1).

In some cases, you may also view as a disadvantage the ability of static analysis to exhaustively check every possible input-to-output path. Static analyzers are notorious for detecting false paths that a design never exercises during normal operation. Thus, you can spend a lot of time instructing the analyzer on which paths to ignore. Hundreds of such paths can exist, however, and engineers may become so bored by the monotony of clicking "ignore, ignore, ignore... " that they accidentally discard a real problem.

The other main problem with static analyzers is that they function poorly or not at all in designs with feedback loops, so you may have to spend a substantial amount of time manually breaking the loops and passing the analyzer several views of the design.

Dynamic-timing analysis

Another form of timing verification, dynamic-timing, or worst-case, analysis, is based on an event-driven simulator and requires the user to specify a test waveform (Figure 4). The key difference between a standard logic simulator and a dynamic-timing analyzer is that the logic simulator uses only one delay for each path, but the dynamic-timing analyzer uses a delay pair: either minimum:typical (m:t), typical:maximum (t:x), or minimum:maximum (m:x). To illustrate the difference between logic simulation and dynamic-timing analysis, consider the way in which each would simulate a simple buffer gate (Figure 5).

With a logic simulator, presenting a new value to input "a" causes output "y" to change after the minimum, maximum, or typical delay, depending on which delay the user selects. By comparison, assuming that you instruct the dynamic analyzer to use the minimum:maximum delay pair, output "y" begins to change after the minimum delay and completes the transition after the maximum delay.

The vertical lines between the minimum and maximum delays do not indicate an unknown X value (Reference 2). This situation is because the "y" output is performing a good transition, but you don't know exactly when this transition will occur. For this reason, the guys who create dynamic-timing analyzers typically call this state "gone high, don't know when." (There would also be a corresponding "gone-low, don't-know-when" state).

Now, assume that the analyzer presents the output from the buffer gate to the input of another gate. This second gate sees the incoming ambiguity and adds its own ambiguity to the signal based on the gate's delays. And, so it goes throughout the circuit, with each gate supplying its own amount of ambiguity until the signal reaches a primary output from the design.

One disadvantage of dynamic-timing analysis is that it is CPU-intensive, being approximately three times slower than logic simulation and much slower than its static-analysis counterpart. Possibly, its main disadvantage, however, is that it doesn't exhaustively check every conceivable input-to-output path, because it can evaluate only those paths that the test waveform exercises. This disadvantage throws the onus onto the user to write a good set of test vectors.

Despite their disadvantages, dynamic-timing analyzers have a major advantage over their static cousins: Dynamic analyzers are suitable for just about every type of circuit, particularly those containing feedback loops, such as asynchronous state machines, which would cause a static analyzer to throw up its hands in horror (Reference 3). Also, dynamic analyzers can detect and report timing problems that static analyzers wouldn't even consider. For example, consider the case of a humble AND gate buried deep in a circuit (Figure 6). Assume that you want input "a" to this AND gate to be driven to logic 0 sometime before input "b" is driven to a logic 1, thereby ensuring that output "y" is held at logic 0. Remember that this gate is embedded in the middle of a circuit, so a chain of other gates is driving each of this gate's inputs. Each gate in the chain has its own m:t:x delays.

In a static analyzer, the only information that the analyzer reports is the total minimum and maximum delays from the circuit's primary inputs, through this gate, and on to the primary outputs. The analyzer can provide a breakdown of each portion of the delay path, but this approach quickly buries you up to your ears in data. In a logic simulator, if you set all of the gate delays to their minimum values and run the simulation, no problems appear to exist. Similarly, the simulator would report no problems if you set all of the gate delays to their maximum values and ran the simulation. However, in dynamic analysis, the analyzer simulates across the range of delays. If the gates feeding the "a" input were from a batch that were running at their maximum delays and the gates feeding the "b" input were from a batch that were running at their minimum delays, then the "b" input could go to logic 1 before the "a" input falls to logic 0. In this case, a glitch could appear at the output from the gate.

In many cases, such a glitch would not be a issue—for example, if the glitch occurs in the middle of one of the blocks of combinatorial logic in a classical synchronous design (Figure 3). However, if this gate were in the middle of an asynchronous state machine, then you have a potential problem on your hands.

Dynamic-analyzer shopping

If you're shopping for a dynamic-timing analyzer, you should consider several things. First, you want the analyzer to be able to attach ambiguity to the signals in your test waveform, thereby allowing you to simulate the effects of skew on the inputs. You can use this ambiguity to represent the skew from other boards and the backplane in your system. Alternatively, if you are writing a waveform to test a single device on an IC tester, then you can use this ambiguity to simulate the effects of skew at the test head.

Adding ambiguity to your stimulus does not mean that you must laboriously modify each edge in the waveform. Instead, you should be able to bring up a dialogue form that lets you specify x nsec of skew on signal "a," y nsec of skew on signal "b," and so forth. When you apply this ambiguity, it should immediately appear in your graphical waveform display for all to see. Also, depending on the analyzer in question, you should be able to specify different amounts of ambiguity both before and after the original edges in the waveform and to specify different skew values for rising and falling edges.

The next thing you should consider when purchasing a dynamic-timing analyzer is the quality of the algorithms it uses to detect and handle reconvergent fan-out, or "common-mode ambiguity." This ability refers to a signal that diverges into multiple paths and then reconverges later (Figure 7). This circuit isn't particularly meaningful, but it illustrates the point. When evaluating the effect of the signals "wb" and "wc" on gate "g4," the dynamic analyzer must recognize the fact that some portion of the ambiguity on these signals came from gate "g1'' and is common to both paths. Thus, the analyzer must remove this common ambiguity from the calculations to prevent the results from being unduly pessimistic.

This occurrence is common in functions, such as shift registers and counters, in which a single clock signal drives several registers. The analyzer must recognize the fact that any ambiguity on the clock is common to all of the registers; otherwise, the analyzer would flag timing problems all over the place. The purveyors of dynamic analyzers may try to blind you with science regarding the quality of their algorithms, but this situation is often a case of "quickness of the hand deceives the eye." The key question you should ask is: "How many levels of logic can the analyzer track and still handle reconvergent fan-out?" If the answer is "one gate," then the analyzer is effectively useless, and you should start to cast your eyes elsewhere.

Last, ensure that your dynamic-timing analyzer supports the concept of "correlation." Even if you don't need correlation this week, you'll find a use for it at some stage. The idea here is that all of the gates in an IC package are correlated to some degree. For example, if you plunge your hand into a bucket of hex buffers and pull two devices out, then, due to process variations and manufacturing tolerances, you stand a fair chance that one of the devices will be fast and the other will be slow. This situation is why manufacturers specify simulation models with m:t:x timings, which, in addition to environmental conditions, such as temperature and voltage, also cover process variations. The point is that, although you don't know whether a particular device will be fast or slow, you do know that each of the gates on that device will be correlated to some extent, and you want your dynamic-timing analyzer to understand and use this information.

For a long time, ASIC designers considered correlation to have application only in board-level designs, because the designers felt confident that all of the gates on a single piece of silicon would be correlated by default. However, in the case of deep-submicron devices containing 100,000 gates or more, minute process variations from one side of a chip to the other can have a significant effect. Thus, the ability to simulate correlation will become increasingly important to ASIC designers in the not-so-distant future.

References

1. Maxfield, Clive "Max," "Digital logic simulation: event-driven, cycle-based, and home-brewed," EDN, July 4, 1996, pg 129.
2. Maxfield, Clive "Max," "'Xs' in digital simulation: Beware, here be dragons!," EDN, Oct 12, 1995, pg 139.
3. Maxfield, Clive "Max," To be or not to be asynchronous; that is the question," EDN, Dec 7, 1995, pg 157.