Taking full advantage of 8b/10b encoding in your USB 3.0 design - Embedded.com

Taking full advantage of 8b/10b encoding in your USB 3.0 design


One of the critical technical advances that enable modern high speed serial data links, such as SuperSpeed USB 3.0, is a data encoding scheme called 8b/10b. 8b/10b encoding is a proven means of overcoming a technical issue that arises when designing systems that use high data rates to transfer data over long distances (depending on the data rate and physical transmission medium, “long” in this context can refer to a few feet or many miles).

The issue that 8b/10b encoding addresses arises due to the nature of the differential receivers that make such high-speed data links possible. So to understand the use of 8b/10b encoding, we first need to understand some requirements of differential receivers.

Differential Receivers
Differential receivers were one of a series of key developments that enabled long distance, high speed serial data links.

Back in the early days of digital electronics, signal transmission was accomplished by having the receiver measure the DC voltage level of the incoming signal against a common ground shared by transmitter and receiver. In this simple world, using TTL logic as an example, a voltage of 0V represented a logical “0” and a voltage of +5V represented a logical “1”.

There were a number of problems in trying to extend this technology to higher data rates and longer distances, and one key problem was the inability to provide a stable and common ground reference level when systems became physically separated. A solution provided for this was the development of differential receivers, where the signal level is measured between two conductors, rather than against a common ground.

While the nominal “ground voltage level” might vary appreciably from one location to another, existing technology such as twisted pair conductors helped ensure that the DC offset was essentially the same for both wires, and therefore the differential voltage between the two remained constant and measurable by the receiver.

Differential receivers were also able to extract the clock signal (to obtain precise location of data bits) from the incoming signal by observing the rate of change of signals on the incoming transmission. By extracting the clock from the data, the receiver is able to “lock on” to the incoming signal and correctly translate the incoming signal back into data bits as originally transmitted by the remote device.

The Need for 8b/10b Encoding
However, there were some restrictions to this approach. One of those restrictions was the need to ensure that the incoming data provided variations in signal level at a sufficient rate that the receiver could continue to track the clock rate. For example, if the data being transmitted consisted of long strings of 0s (or of 1s), the receiver would see what appeared to be no signal on the line, and the “lock” would be lost.

A second problem was that, to function well, the differential receivers required the incoming data to effectively be DC-neutral, in other words that over periods of time longer than a few bits that the number of 1s received roughly matches the number of 0s received.

Both these constraints are not typical of real data, which often contains long strings of 0s or 1s (for example as filler at the end of a data file).

The solution to this issue was the development of an encoding scheme, in which the “real data” would be encoded using a scheme which ensured that no more than five “0” values or five “1” values would ever occur in a row, and also ensured that over time the total number of 1s transmitted would closely match the total number of 0s.

In order to accomplish this, each 8b byte was encoded into a 10b symbol. By adding two extra bits to each byte, the potential range of data symbols was four times as large as the possible range of original 8b bytes. By careful selection of values from this much larger range of possible symbols, each 8b byte could be encoded using a 10b symbol chosen to ensure that no more than five “0” values or five “1” values occurred in a row.

Furthermore, since the 1:1 encoding of bytes into symbols used up only a quarter of the available symbols, a second set of symbol codes could be selected for every possible 8b byte, and furthermore be selected to help compensate for excessive 0 or 1 values in the previously transmitted symbol(s).

So in 8b/10b encoding, each data byte has two different symbols, one selected to have slightly more “1’ values and the other to have slightly more “0” values. These different symbols are called positive and negative disparity, and the transmitter keeps track of the disparity and selects the appropriate symbol for the next byte to compensate for any disparity introduced by the previous symbol.

The entire 8b/10b encoding and managing this “running disparity” is handled by the physical layer and is completely transparent to higher levels of the firmware/software stack, which see only 8b data values. However, for test purposes it is critical to understand that the native data traffic actually being transmitted in a USB 3.0 data link is always being transmitted entirely in 10b symbols.

Designing USB 3.0 Test Equipment
All SuperSpeed USB 3.0 analyzers rely on PHY silicon to perform the critical role of LFPS detection and data deserialization. There are two basic approaches to designing the analyzer’s data recovery circuitry.

Figure 1. When framing errors occur, the PIPE PHY-based analyzer sets a flag that indicates the symbol did not decode properly. But it’s not possible to see the actual raw 10b symbols that were received with errors. Instead of showing the actual bits for framing errors, the analyzer simply substitutes “D” characters for “K” characters to imply an error. These analyzers may show valid 10-bit codes but only by reverse calculating the values using valid 8-bit symbols. 

Some USB 3.0 analyzers rely on commercially-available SuperSpeed PIPE PHYs (Figure 1 above ), while others are custom designed with general purpose deserializer components to allow direct access (Figure 2, below ), capture and recording of the native 10b traffic.

The main limitation when considering test equipment that uses USB 3.0 PIPE PHYs, like the Texas Instruments TUSB1310, is that the PIPE interface on this chip does not preserve the 10-bit symbols on the bus.

Figure 2. When link framing errors occur, deserializer-based analyzers show that the symbol was not valid by marking in red. The actual 10b symbol (3A9) is shown by “drilling down” to the native 10b trace recording, allowing developers to see transmission errors or bit flip errors. Running disparity is also preserved allowing users to distinguish running disparity errors from other encoding errors. 

Since the 8b/10b endoding/decoding and running disparity process is defined as a physical layer function, this PHY (and other “off-the-shelf” PHYs) converts the data stream to 8-bit patterns before transferring to the analyzer logic. In the process, it discards the original 10-bit patterns including running disparity.

Without the running disparity information, it becomes impossible to accurately recreate the 10b symbol, especially when an invalid 10b symbol is received. While the TI PIPE PHY can indicate receipt of an invalid 10b symbol, it cannot identify which invalid 10b symbol was received.

Also, while PIPE PHY may indicate a running disparity error, it cannot identify the disparity value that was received or the previous symbol’s running disparity.

Showing Actual 8b/10b codes
Header packets and link commands are designed to tolerate a single bad symbol within their packet delimiters. When these errors occur, SuperSpeed devices are required to accept these packets as long as three out of four framing symbols are valid. Both analyzer approaches can detect when 10-bit symbol errors occur.

The difference indicates that PIPE PHY based analyzers do not show the actual 10-bit symbol when it contains an error. This is easy to see using USB-IF Link Layer test case 7.05 (Header Packet Framing Robustness) that intentionally corrupts the HP framing. Only analyzers that capture and preserve raw 10b symbols allow users to see what was actually received.

This is important in attempting to resolve problems in developing new SuperSpeed USB 3.0 products, because although a PIPE PHY based product can inform the user in invalid symbol was received, no other information about the symbol is available, so engineers cannot differentiate between, for example, an encoding error associated with a specific 8b byte and a hardware issue that repeatedly introduces incorrect bits into specific locations in the data stream.

The inability to directly identify the invalid symbols means more time lost and more expensive test equipment required in tracking down the source of the problem so that it might be resolved. Both analyzer approaches can detect and report errors in the payload portion of headers, data frames, and link commands (using CRC checks).

However, analyzers that utilize the PIPE PHY only have access to the 8-bit bytes to analyze the traffic. This is normal for commercial PHYs because higher layers only use the 8-bit values. However, when it comes to test equipment, developers generally want to capture the most detailed picture possible of traffic on the bus (ie: header packet framing error example above).

In the event developers using PIPE PHY based analyzers need visibility to 10-bit errors in link or header framing, the only alternative is attaching a scope to the system-under-test to capture the raw bit information.

When it comes to debugging link layer or 8b/10b encoding issues users will benefit having this additional information from the analyzer (Figure 3 below ).

Figure 3. Both the Voyager M3i and Advisor T3, shown above, use deserializer components & feature true 10b symbol capture for uncovering root cause issues effecting USB 3.0 link stability.

Visibility to the native 10b symbols captured at the physical layer can help uncover root cause issues effecting link stability, resulting in faster problem resolution and quicker time-to-market for new USB 3.0 product designs.

Mike Micheletti is USB Product Manager for theLeCroy Protocol Solutions Group, which includes the company’s USB 3.0 analyzers, the Voyager M3i and the Advisor T3 which utilize custom designs using deserializer components and feature true 10b symbol capture.

Leave a Reply

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