High-speed digital systems normally require system characterization and debugging, two of the most time-consuming aspects of the product development process. Development schedules can easily slip, due to unpredictable system integration problems. Thus, a need has developed for the test and measurement features available with today's digital storage oscilloscopes (DSOs). The DSO's powerful signal capture, display, and analysis capabilities can be used to effectively debug and characterize signals, simplifying the processes and reducing time-to-market.
When selecting a scope for debugging and characterizing digital systems, it is important to consider the scope's ability to not only capture and faithfully display the signals of interest, but also to analyze them. The latter aids in solving problems by speeding up the debug and characterization process.
Modern DSOs provide a broad range of capture, display, and analysis capabilities. These include a variety of trigger types, color-graded and persistence (analog-like) displays, automated parameter measurements, histograms, trending, pass/fail testing, and sequential capture with time stamps. For effective signal analysis, it is also important to consider the DSO's processing speed and memory.
Two examples demonstrate the use of DSOs to debug and characterize digital systems. Traditional, as well as new techniques, now exist as a result of advancements in the capture, display, and analysis of digital signals using DSOs.
The test results of an early production run of an Intel 386DX-based controller board indicate many instruction-cache diagnostic failures. Some boards successfully pass the cache diagnostic test and subsequently fail when running the application program, while others always fail. All boards run properly when their caches are disabled. Due to the diagnostic program's limitations and the nature of the failures, it is not possible to determine the reason for the failures.
A simple debug program that exercises the bus is run on a defective board. The debug program successfully loops, and intermittent failures do not occur. An analog or digital scope may be used to observe the cache control signals: write enable (—WE), chip enable (—CE), and output enable (—OE). Observations of the control signals—on all nine cache chips—appear to be of normal shape, duration, and level.
Using a DSO, the basic bus cycle is confirmed and found to be operating normally. Figure 1 shows (from top to bottom) the 66.7-MHz CPU clock, the address/data bus stable flag (— ADS), —OE, and the cache —CE. A DSO is used, since it can be more effective in viewing nonrepetitive signals than an analog scope.
The bus logic appears to behave normally. This points to an address or data problem. Two critical timing paths are associated with the cache controller: one for the cache address latch enable, and one for the SRAM output enable (Fig. 2).
For simplicity, a persistence display is used to look for anomalies. Figure 3 shows the bus clock and one of the cache data lines, displayed using an LC574 DSO in color-graded persistence mode. In this display mode, the most common events are indicated by the hottest color—that is, red. As the figure demonstrates, persistence displays can be difficult to interpret when viewing bus signals. The data bit displays complex behavior, including undershoot, "runts," and edges with different rise times (which makes the clock appear to jitter in the display).
At first glance, it would appear that there are a variety of timing problems. Closer examination, however, reveals that the display actually shows normal system behavior. The runts appearing near the rising edge of the data line are approximately one CPU clock in duration—a perfectly legal condition, considering a complete bus cycle requires two CPU clocks. The undershoot, while undesirable, is well within expected values.
The CPU data bus is multiplexed, making it impossible to tell which device is driving it at any given time. Variations in propagation time from one device driver to another can easily explain the observed 2 ns to 3 ns variation in fall time. The larger rise time variations are most likely caused by timing differences between cache and CPU cycles.
In general, viewing digital signals by using a persistence display, without the benefit of a qualifying trigger, provides little useful information. In this case, observing the cache data and address lines, using a persistence display while triggering on the cache output enable, proves to be more effective.
Figure 4 shows (from top to bottom) the clock, data line D6, data line D4, and —OE. Using the scope's relative time cursors, a 3-ns delay is measured between the crossings of the two data lines.
Additional measurements indicate that the falling edge of data line D4 is slower than all of the other cache data lines. The slow edge may be the cause of the failure, since the cache's SRAM chip requires a minimum —OE-to-data delay of 10 ns to meet the microprocessor's setup time spec.
The accumulated results lead to a conclusion: there is a cache-read problem, due to a defective SRAM. But, replacing the SRAM does not solve the problem. This should have been expected, because more than one board is failing in the same way.
The signals are viewed again using single-shot acquisition. The timing is analyzed using the scope's automated measurement parameters.
The Δt@lev parameter is used to measure the delay from the falling edge of the cache-output enable to both the rising and falling edges of D4 and D6 (Figs. 5 and 6). The Δt@lev parameter can accurately measure time delays between two signals by independently selecting a reference level, edge (positive, negative, or first edge), and hysteresis setting for each signal.
Automated parameter measurements are performed on the signal region lying between the cursors. This provides the capability of measuring the timing on selected cycles.
Reprints
