The amount of real-time-scope memory you need for serial-data analysis depends on what you want to accomplish. Examining a few common validation and troubleshooting task helps determine how much memory you need.
Typical clock-recovery software packages include an option for the software to emulate a PLL with variable frequency response. When you choose this option, the algorithm requires some number of cycles to lock onto the clock. The data in this locking range is unavailable for measurements, and you need to take that fact into account in planning memory requirements. The amount of memory required depends on a number of factors-primarily, the clock frequency and loop bandwidth.
You can evaluate the memory question from the perspective of three common tasks: examining low-frequency jitter or infrequently occurring jitter or noise events, examining all the combinations of bit sequences in a PRBS (pseudorandom binary sequence), and achieving a desired confidence level of meeting a given bit-error rate.
Low-frequency or infrequent jitter If you want to measure the jitter from the serial- data signal modulated at a low frequency, you've established a requirement for memory depth. For example, if you have a 2.5Gbps signal captured by a scope with a 20G-sample/sec sampling rate and 1M-sample of memory, you capture 50µsec of elapsed time, allowing you to view one cycle of jitter at a frequency of 20kHz.
Measuring low-frequency jitter is usually not a requirement for serial-data analysis, because the clock-recovery PLL in most serial-data receivers can effectively reject jitter at moderately low frequencies. But an event occurring at a low repetition rate can sometimes cause bursts of jitter or noise that contain higher frequencies that the PLL cannot reject; therefore, you need to plan for such events. Figure 1 shows an example of this type of signal crosstalk. The yellow trace is a serial data signal, the green trace is an uncorrelated aggressor signal from somewhere else in the system that is causing short-term bursts of jitter in the data signal, and the purple trace is a jitter-trend signal derived from the serial-data signal. This jitter trend is simply a time plot of the timing of each edge in the data stream compared with the "idealÓ" recovered clock. You can see the burst of timing errors that coincides with each transition in the green aggressor signal.
Figure 1: Coupling from one signal (green) causes jitter on another signal (yellow). The purple trace is a jitter-trend signal derived from the serial-data signal.If the data rate of your signal is appropriate, you may be able to use a lower sampling rate to extend the time captured on each trigger. For example, for a data rate of 1Gbps, you may be able to sufficiently capture all the frequency content of the signal at a sampling rate of 10Gbps. In this case, 1M sample of memory captures 100 µsec worth of data, allowing you to see a full cycle of jitter at 10kHz.
Table 1 shows the minimum jitter frequency, or burst-occurrence rate, that a scope that samples at 20G samples/sec can capture as a function of memory depth. Note that even the deepest memory scopes available on the market today don't capture jitter frequencies as low as 60Hz or even 120Hz when sampling at 20G samples/sec. If you suspect that something in your power supply is sending out bursts of noise or jitter at power-line crossovers, a useful troubleshooting technique is to trigger on the power-line and then see whether there is a stable burst on the jitter trend waveform.
Most switching power supplies operate at frequencies higher than 20kHz, so 1M sample of memory in a scope sampling at 20G samples/ sec is usually sufficient to capture problems correlated to switching power supplies.
Examining all the combinations in a PRBS One advantage of using a PRBS as a stimulus in testing systems is that it contains all the possible sequences of numbers of ones and zeros, limited only by the length of the PRBS. A 2N-1 PRBS sequence contains one sequence of N-1 zeros followed by N ones, along with all combinations of
The length of a PRBS pattern you should use depends on the serial bus that you're designing. The longest run of consecutive ones or zeros in the PRBS you choose should match the longest consecutive run of ones or zeros in the serial bus you're designing. If your bus uses 8b/10b encoding, for example, you only need to test using a 25-1 PRBS.
To view the effects of all the various combinations, you should capture the entire PRBS. If you analyze a single acquisition that is shorter than the entire PRBS, you'll miss some combinations. By running repetitively, you may still have a fair chance of seeing all the parts of the sequence after some indeterminate time, because the scope will most likely retrigger randomly at various points within the PRBS. But capturing the entire PRBS on each trigger or on a single trigger gives you 100% reassurance.
Table 2 shows the memory required to capture all of a PRBS sequence for a 2.5Gbps bit rate and a scope sampling at 20G samples/sec. The mathis straightforward for other combinations. Note that even the deepest memory scopes on the market today can't capture a complete 232 -1 PRBS sequence in one acquisition. 27-1 and 211-1 are common patterns; both fit easily into 256k samples of memory. A 216-1 sequence fits into 1M sample of memory with room to spare. For sequences that Table 2 does not show or for other sampling rates and data rates, you can easily calculate the memory required using the number of cycles captured=[(memory depth)*(data rate)]/(scope sampling rate), extrapolating to a desired bit-error rate.
How long do you need to let a scope mask or jitter test run before you can feel confident that your system will meet a given bit-error rate? Statistically, you can word the problem as follows: For a bit-error rate of, say, 10-12, you could have a large number of errors in the first few bits you examine; on the other hand, you could also see zero errors in 1016 or any arbitrarily large number of consecutive bits.
You could wait a long time and determine the measured bit-error rate, but that could take an unnecessarily long time, especially if you never see any violations. Assuming that you get no violations, you can calculate the confidence interval for predicting a given error rate from less data. For example, for a given BER (bit-error rate), Table 3 shows how many error-free bits you would have to observe to achieve the confidence level in the table.
Note that, although the correlation between a scope and a BERT (bit-error-rate tester) is good, a scope gives you only an estimate of the bit-error rate, not a measurement. To achieve the ultimate confidence that you've met your error-rate goals, you need to use a BERT, particularly for small error rates. The problem is that, even if the scope had no inherent jitter or random noise, it only captures a subset of the data, whereas the BERT examines every bit.
Assuming that you do see some errors, then Table 3 and extrapolation are invalid. In that case, you need to let the system run until you see 10 to 15 errors to have confidence that the number of violations divided by the number of UIs (unit intervals) tested is a good predictor of the long-term BER. That process can take an indeterminate time, assuming that errors occur randomly.
Table 4 shows the relationship between memory depth, number of UIs captured on each acquisition, and the total number of acquisitions required to achieve 95 and 99% confidence of less than 10-12 BER. The table assumes, again, a 2.5-Gbps data rate and a scope sampling at 20Gsamples/sec. You can see that, even with 100M samples of memory, it takes a long time to achieve a high level of confidence of low BERs.
Many scopes with serial-data-analysis packages report the number of UIs examined and the number of failed UIs. You can calculate how many UIs each acquisition contains, as follows: number of UIs=(memory time duration)*(bit rate); memory time duration = (memory depth)/ (sampling rate); thus (number of UIs)=[(memory depth)*(bit rate)]/ (sampling rate).
Advantages of software clock recovery
If you're after statistical confidence, keep in mind that scopes that recover the clock in software and reconstruct the eye diagram from that clock have significant advantages over older methods of eye-diagram measurements. In the good old days of separate clocks and data, you triggered the scope on the clock signal and viewed an eye diagram of the data signal, which made the measurement susceptible to trigger jitter and false triggers. Trigger jitter in the scope added to the jitter of the measurement. With clock recovery in software, trigger jitter does not affect the measurement results. The scope could be triggered on anything, or it could be free-running with no active trigger source at all.
All scopes have some rate of false triggers, caused by violation of setup and hold in successive stages of the trigger flip-flops. Although the rate of false triggers is low, it can affect the measurement statistics for low BERs. Once again, with software clock recovery, false triggers are not a problem. These advantages combine to yield much greater confidence in measurement results by using software clock recovery.
Author Information
Art Porter is a sales support engineer at Agilent Technologies, where he is responsible for high-performance oscilloscopes. In his 41 years at Agilent Technologies and its predecessor, Hewlett-Packard, he has worked in product development, manufacturing, and marketing roles. Porter has authored a variety of articles and application notes and presented a number of Web seminars in the area of signal integrity.
