Troubleshoot and verify 8b/10b encoded signals with a real-time oscilloscope - Embedded.com

Troubleshoot and verify 8b/10b encoded signals with a real-time oscilloscope

Few serial technologies have become more widely adopted than 8b/10b coding, which is now used in standards like PCI-Express, Serial ATA, SAS, Fibre Channel, InfiniBand, FireWire, MIPI M-PHY, HDMI, DisplayPort, CIPRI, OBSAI, XAUI, USB3.0 and others.

Therefore, any designer will eventually need the ability to efficiently analyze 8b/10b encoded signals using common instrumentation such a real-time oscilloscope. The intent of 8b/10b line coding is to achieve DC balance and provide enough state changes to ensure stable clock recovery. Since DC balance is maintained, 8b/10b signals can be transmitted through transformers, optical channels or AC coupled links which have DC offsets at the pins of their integrated circuits.

AC coupled data signals would have DC drifts depending on the data content. A long sequence of 1s will lead into positive drift and many 0s will drift toward negative voltage, as shown in Figure 1 below. Without correction it will cause errors at the receiver side since a fixed threshold is being compared to the drifting voltage level of the data signal.


Click on image to enlarge.

Figure 1. DC drifts without 8b/10b encoding.

As shown, 8b/10b line coding will compensate for these effects by mapping 8 bits of data to 10 bit symbols (or characters). Each 8 bit word corresponds to two 10b characters to ensure the long term ratio between 1´s and 0´s is nearly 50 percent, as outlined in Figure 2 below.

The difference in numbers between 1s and 0s is called “running disparity” (RD) and it is either +1 or -1. Therefore the encoding of one 8 bit data word will change depending on the preceding symbol at the speed of the data rate.


Click on image to enlarge.

Figure 2. 8b/10b coding maintains DC level and ensures clock recovery.

With high-speed serial signals now delivering multiple gigabits per second, they require very high bandwidth in the physical layer for their links. One way to verify the performance of serial links is compliance testing. Usually compliance tests are used for characterization at a final state of the design. If the compliance test passes everything is fine. If not, debugging of the physical layer might become necessary.

A first step is often to look for measurements that are out of range related to the appropriate standard’s specifications. This can indicate where to perform further measurements and suggest actions to solve the problem. If this does not solve the problem, the engineer can look at a composite of all data values and transitions on the bus using an eye diagram.

The eye diagram can show issues related to noise, jitter, and signal integrity. It can also be used to check for violations of an eye diagram mask which are specified in many industry standard compliance tests. Any kind of degradation of the signal will cause less margin or more hits in the eye mask.

This degradation can indicate significant problems in the physical layer (PHY) design. Examples of signal integrity issues that can lead to mask test failures include slow signal rise time (bandwidth), small signal amplitude (attenuation), large overshoot (inductance), or large jitter and noise components such as cross talk and intersymbol interference (ISI).

Debugging protocol errors
Issues with the PHY layer will often cause intermittent faults. Usually PHY verification and protocol testing are done with different test equipment and under different conditions using an oscilloscope.

Figure 3. Conversion of waveform data into protocol.

To ensure best signal fidelity and highest timing resolution, the engineer should evaluate the link at the compliance test point with an oscilloscope and convert the acquired “analog” waveform into binary values or even characters and commands.

The protocol trigger and decode software can be used to convert the waveform data into a binary format by recovering the clock first and comparing the voltages with a user-defined threshold and some hysteresis. A block diagram of how this software works is shown in Figure 3 above, with results shown in Figure 4 below.


Click on image to enlarge.

Figure 4. Protocol view of characters, protocol and waveform.

As shown, there are two tables that list the characters and the protocol. The protocol is correlated to characters and to 0s and 1s in the acquired waveform. This makes is easy to track errors in the protocol down to the physical layer.


Click on image to enlarge.

Figure 5. Tracking a protocol failure to a glitch in the waveform.

The displayed waveform in Figure 5 above can be useful to understand why wrong 0s and 1s have been possibly misinterpreted by the receiver. Cursors and the actual zoom window can be synchronized with the scope waveform display and can helpful in locating the cause of the protocol error.

Capturing Specific Data Values
Searching for a specific character in the protocol table is a common method to locate protocol errors in the data stream. But searching is a post acquisition process and is limited to a time frame that is set by the size of the acquisition memory. The dead time between acquisitions is quite large and is caused by oscilloscope and the processing time of the software for interpreting the waveform into binary and then searching for the character. This is illustrated in Figure 6 below.


Clickon image to enlarge.

Figure 6. Dead time between acquisitions.

Therefore, as shown above, the chance of capturing any infrequent and rare faults is very low. For example if there are 10 million points sampled at 50 GS/s, the real time acquisition will stop after 200 microseconds. But it will take hundreds of milliseconds before the system can capture the next block of 10 millions points. Larger memory will even increase the problem. To find rare events it is necessary to trigger on those faults.

Most digital oscilloscopes provide a large portfolio of triggering capabilities. Traditionally, troubleshooting is related to time and level qualified triggering. With the advanced trigger modes available, triggering on glitches, transitions, runts and so forth is much easier than in the past.

For protocol errors, it can be useful to trigger on commands, characters, or bit sequences. Unfortunately a serial trigger circuit designed for NRZ patterns cannot find those faults because most high speed serial data signals are 8b/10b coded and require a dedicated hardware solution.

A standard NRZ trigger cannot trigger on words of 8b/10b coded data streams because of two reasons. First, the coding of the 8 bit word to 10b symbol will change at the speed of the data rate and would require an adjustment of the symbol rate in the trigger memory to the same speed.

Second, triggering on the right 8b/10b symbol requires synchronization or alignment of the 8b/10b codes to the data stream. For real time triggering the hardware must be capable to synchronize to one of the “comma symbols” (K.28.1, K.28.5, and K.28.7) which are unique and cannot be found in the data stream at any bit position in the code.

The synchronization character can be somewhere in the data stream and might be very infrequent or appear only once. One example for a synchronization character is the comma symbol, K28.5 (011110101). Once the alignment symbol has been found, the decoding of the subsequent symbol values can proceed.

Software “triggering” solutions actually perform a search through the acquired data and therefore have long dead times that cause very large gaps between the acquisitions and increase the chances of missing the character in question.

Many higher end oscilloscopes are equipped with a dedicated trigger chip for triggering on 8b/10b data patterns in high speed serial signals up to 6.25 Gb/s. This enables the instrument to find rare events since it is now able to trigger on 8b/10b characters.

Characters are acronyms for a pattern of 10 bits of the 8b/10b code, i.e. D31.6 or K28.5. A second option related to a high speed serial standard’s protocol is triggering on 8b/10b words (commands), where words consist of multiple characters (commonly 4 words or 40 bits). It should be noted that every standard has its own word definitions.

A powerful debugging tool is the ability to trigger on 8b/10b code errors. No serial trigger would be able to trigger on all possible character errors, disparity errors or losses of byte synchronization, but it is usually possible to trigger on common errors such as disparity or character errors.

Network element delay measurements
Triggering on 8b/10b serial patterns can be used for measuring the time delay of an active network element. One might think this an easy task to solve even without special triggering on 8b/10b. But it can be challenging when it’s necessary to measure the time delay under real conditions. The setup for this measurement is shown in Figure 7 below.

The input signal of the network element is connected to Channel 1 and the output data stream is connected to channel 2 of the oscilloscope. A data generator will provide the required data stream to the input of the network element (DUT).

A unique pattern inside the data stream will perform as a timing reference. This timing reference needs to be a very rare pattern to prevent confusion with another timing position. If the pattern has been defined you can search for that pattern in the acquired signal of channel 1 and channel 2 and then measure the time between the two locations.

Figure 7. Time delay measurement setup

A software decoding function could help to find the sequence in the data stream. Because of its infrequent occurrence the search for the pattern can be very difficult. Given oscilloscope acquisition memory limitations, the chance of finding the pattern for the timing reference is low. Unlike searching, 8b/10b triggering makes it much to find the sequence. This is because triggering ensures that the pattern will always be inside of the acquisition window.

Without 8b/10b triggering the delay measurement would require a trigger signal from the data generator to the oscilloscope. That would be the only way to synchronize the starting point of the 8b/10b timing reference at the output of the data generator with the acquisition window of the oscilloscope. However, this method fails to replicate real world conditions.

In the set up shown in Figure 7 above , a bidirectional link connects the two network elements. Network element A acts as a data source to ensure that network element B (DUT) works in a desired operating mode. The communication link has to be established by proprietary commands and the data flow of this commands needs to be maintained during the measurements to keep the DUT in the desired operation mode. Therefore a static data pattern provided by any data generator will not work.

Similar to the previous example a unique pattern is required for a timing reference (marker) in the data stream. Since the pattern is very infrequent and there is no trigger signal available from the source network element A, an 8b/10b trigger is required to find the pattern in the input and the output signal of the DUT.

The optimum way to see and measure the delay between the input and output of the network element is to use two zoom windows. The first zoom window is placed at the beginning of the pattern sequence at channel 1 and the second zoom window at the beginning of the pattern sequence at channel 2. For the delay measurement the acquisition time window of the oscilloscope should be equal to or greater than the delay time.

Summary
Test equipment with features designed for serial bus test, such as triggering on and decoding of serial data, can dramatically improve engineer productivity and lead to more reliable, higher performing designs. One of the most important serial technologies is 8b/10b coding which is used in more than a dozen high speed data standards. As discussed here, troubleshooting and verifying devices with 8b/10b serial buses can be greatly enhanced through the use of oscilloscopes with real time triggering of 8b/10b coding information.

Chris Loberg is a Senior Technical Marketing Manager at Tektronix responsible for Oscilloscopes in the Americas Region. Chris has held various positions with Tektronix during his more than 13 years with the company, including Marketing Manager for Tektronix’ Optical Business Unit. His extensive background in technology marketing includes positions with Grass Valley Group and IBM. He earned an MBA in Marketing from San Jose State University.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.