Design Automation

Fixing Some Glitches is All in the Timing

Undetected output signal glitches can cause quality and yield problems.

by Michael J. Peters

Glitches on output signals can easily be overlooked by tools that convert simulation results into test vectors. Typically, the timing of these glitches will vary with changes in the fabrication process, power supply voltage, and operating temperature of the device. While the output signal may appear to be stable at the required time in the simulation results, in reality, an output glitch may move through this "stable" region as process/temperature/voltage vary. This problem will often go undetected during simulation analysis and will result in reduced test yields and intermittent field failures. In this article, I will describe a method for detecting and reporting such situations.

Much effort has been spent in recent years toward improving ASIC quality. In the area of test, the majority of these efforts has been focused on design techniques to enhance testability, software tools to generate tests automatically, and methods of measuring the effectiveness of the resulting tests. While great strides have been made in these areas, most of the ASICs developed today do not make use of built-in self-test (BIST) or automatic test pattern generation (ATPG), and while quiescent power supply current (IDDQ) testing is becoming widespread, it is still used mainly to supplement other test methods. Conversion of logic simulations into automated test equipment (ATE) vectors is still the most common method of ASIC test development.

Logic simulators and the tools used to extract test vectors from the simulation results have been around for years. Steady improvements have been made in the accuracy, efficiency, and capacities of these tools. In most cases, these tools are very effective in producing thorough, accurate, high-quality tests. Still, there is room for significant improvement even in mature techniques such as these. Even with the best tools and a vector set that achieves extremely high fault coverage levels, test quality problems can still exist. There can still be field failures due to insufficient testing, situations where circuits perform flawlessly during testing and then exhibit problems when plugged into the system for which they were designed. There can still be unnecessary yield loss, situations where perfectly good circuits are rejected needlessly by the ASIC vendor during testing. The cost of these types of problems can be enormous.

Certainly, there are numerous possible root causes for the problems described above. However, one root cause has been identified as being extremely common. We found it to occur in 45 percent of over 200 ASIC designs that were analyzed over a two-and-a-half year period. Its existence can easily be detected through a more thorough analysis of the same logic simulation results already being used to extract the ATE vectors. The situation being described is due to glitches on output signals that go undetected through simulation analysis and test vector extraction.

Of course, not all glitches on output signals cause problems. In many cases, glitches occur just before or just after a "valid" data region; that is, a region where the signal is required to remain at a stable output state. These glitches pose no problem for ASIC test or system performance. However, some glitches occur during the valid data regions which can violate the circuit specifications and result in incorrect performance. Still, in many cases, the tools used to extract test vectors from logic simulation results can detect these glitches and identify the problem. There is yet another type of output glitch, however, that violates the valid output data region but avoids detection by most test vector extraction tools. This is the situation that, as previously mentioned, we have found to occur in 45 percent of the ASICs that have been analyzed.

Figure 1. Two simulations are needed to identify the range of glitch movement.

To better understand the nature of these glitches and a method by which they can be detected, let us first examine the variability of circuit performance and the nature of logic simulations. It is fairly obvious that the performance of ASICs, as well as that of most other electronic circuitry, changes with variations in the fabrication process, operating temperature, and supply voltage. Each of these parameters can affect the speed at which a circuit will perform. Taking these variations into account, two performance extremes can be envisioned: a "best-case," where all of the parameters are at values which result in the fastest possible circuit operation; and "worst-case," where the parameters result in the slowest possible operation. A given ASIC could exhibit performance anywhere between these extremes.

Logic simulations, on the other hand, tend to model circuit behavior based on one specific set of parameters. To fully analyze the possible variations in circuit performance, multiple logic simulations must be performed using different circuit delay parameters to model the effect of process/temperature/voltage variations. At a minimum, two logic simulations should be performed: one using delay parameters representing best-case conditions, and one for worst-case conditions. The results of both simulations should be considered when extracting test vectors from simulation results.

With this in mind, consider the waveforms shown in Figure 1 . The top trace represents the performance of an output signal of an ASIC under best-case conditions. The bottom trace represents the same output signal's performance under worst-case conditions. The narrow pulses shown at points A and B represent the glitch. As expected, the glitch occurs earlier under best-case conditions than it does under worst-case conditions. In both cases, the glitch does not violate the valid data region; the signal appears to be stable (and free of problems) where required in both cases. As conditions vary from best to worst, however, the glitch moves from point A to B. Under certain conditions, it will occur during the valid data region and cause problems.

While such glitches are the root cause of many of the yield loss and field failure problems described earlier, the test vector extraction tools must share in the blame. The problems would not occur if the tools had detected the glitches and analyzed their movement. Unfortunately, most test vector extraction tools base their results on the use of a single simulation run which does not provide enough information to perform glitch analysis. Even those tools which make use of best- and worst-case simulation results do not consider glitch movement during their analysis. As a result, the glitch problems go undetected.

Figure2. The composite waveform is created by combining those of the best- and worst-case simulations. Use of composite waveforms simplifies analysis of glitch movement.

Now that we understand the nature of the problem, we can focus on a method of detecting these glitches. As I alluded to earlier, one method would be to perform more simulation runs at various points between best- and worst-case. While this is a potential solution, an appropriate set of simulation conditions would be difficult to select and costly to perform. It would be much more efficient and effective to simply project the range of glitch movement given the boundary points identified in the best- and worst-case simulations. This is the approach taken by the simulation and test automation tools designed here at Symbios Logic (Fort Collins, CO).

To accomplish this, we developed a method to simplify the analysis of best- and worst-case simulations. This method involves combining the two simulation results into a "composite." Figure 2 shows the composite waveform that is created by merging some sample simulation results. The composite waveform is composed of two types of signal states: equivalence states and difference states. An equivalence state occurs where the signal exhibits the same state in both the best- and worst-case simulations. A difference state occurs when the signal exhibits different states in the two simulations. The "0" states shown in the composite waveform are examples of equivalences states. The "^" state which occurs in the composite waveform between times 20 and 25 and the "v" state which occurs between times 50 and 55 are examples of differences states. The "^" state represents the combination of a best-case logic 1 state with a worst-case logic 0 state. The "v" state represents the combination of a best-case logic 0 state with a worst-case logic 1 state. With this in mind, the use of composite states can now be applied to the task of output signal glitch detection and analysis. As you can see from the composite states shown in Figure 2 , the ^-0-v state sequence can be shown to depict a glitch moving through a region of logic 0 data. Similarly, a v-1-^ state sequence can be shown to depict a glitch moving through a region of logic 1 data. If a ^-0-v sequence is detected on an output signal and that signal is required to be stable at some point during the "0" portion of the sequence, an output glitch problem has been detected. Figure 3 provides an example of such a situation. In this case, the valid data region is shown to occur from time 33 to 43. Since the glitch moves from time 20 to time 50, it will violate the valid data region as it moves.

By reporting these situations, the Symbios test vector extraction tool allows the designer to take corrective action before the glitches cause real problems. There are two main courses of action that the designer might choose. First, the designer might choose to change the circuit or its timings to eliminate or move the glitch. This is the most common solution to the problem. In other cases, the designer may decide that the output signal does not really need to be stable during the valid region in a particular clock cycle. If this is the case, the designer can indicate this fact to the test vector extraction tool. When this occurs, the resulting test vectors avoid examining the output signal during this time.

Figure 3. This glitch will move through the valid data region as conditions vary between best and worst case.

The glitches that have been described above are fairly simple. There are, however, variations of the glitch problem that are more difficult to deal with. These variations occur when the glitch does not appear in both best- and worst-case simulations. These are referred to as partial glitches, in contrast to the full glitches which were described earlier. There are two types of partial glitches: best-case only glitches and worst-case only glitches. Figure 4 shows an example of each.

The best-case only glitch shown in Figure 4a is identified by the 0-^-0 state sequence, while the worst-case only glitch shown in Figure 4b is identified by the 0-v-0 state sequence. Similarly, a 1-v-1 state sequence is a best-case only glitch surrounded by logic 1 data and a 1-^-1 state sequence is the matching worst-case only glitch. Note that a 0-^-0 partial glitch followed by a "v" difference state is really a ^-0-v full glitch rather than a partial glitch. To identify a best-case only partial glitch, you must look ahead to the following state transition to insure that you have not actually found the beginning of a full glitch. For worst-case only partial glitches, you must look back in time to the preceding state transition.

Not only are partial glitches somewhat harder to detect than full glitches, their movement is also harder to analyze. With full glitches, the boundaries of the glitch movement are clearly identified by the best- and worst-case positions of the glitch. A partial glitch, however, provides a boundary on only one end. The assumption is that at some point between the best- and worst-case conditions, the glitch stops occurring. Just how far the glitch moves before it goes away is not clear.

Figure 4. Partial glitches are those that appear in only one of the two simulation cases.

To precisely locate the missing end point of the movement would require numerous additional simulations which are not practical. Instead, a workable alternative is to estimate the amount of glitch movement based on the knowledge of the circuitry. This estimate can then be used to determine whether the glitch is likely to violate the required valid data region for the signal. The test extraction tool allows the user to specify an estimated glitch movement for partial glitches. This value is then used in determining whether or not the glitch causes a problem. Problem glitches are then reported by the tool to allow the user to take the appropriate corrective action.

Without the ability to detect and analyze the existence and movement of both full and partial output signal glitches, it is very easy for problems to pass undetected. In some cases, the result is only minor test yield loss or minimal field failures. In other cases, the problems can be more catastrophic. In any case, the capability exists in the Symbios tool suite to detect and prevent these problems from occurring. The use of these tools and techniques has been found to effectively identify these problem glitches and eliminate this source of quality problems.

Mike Peters is a Consulting Engineer in the Test Engineering group at Symbios Logic (Fort Collins, CO). He received a B.S. in Engineering Science from the University of Cincinnati in 1982. From 1988 to 1993, he was a member of the Test Automation Tools development team in the Software Development group at NCR Microelectronics (Fort Collins, CO). During that time he led the development of NCR's. Design Test tools for ASIC simulation and test automation.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to: michael@asic.com.