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.