If your company is at the forefront of the PC industry, by now you are probably aware that USB 3.0 is here. Controller chips are starting to ship, and you are already dealing with design issues around the specification.
To meet time-to-market demands, it’s critical for you to ensure your design meets the specification on the first turn. You may be asking, “Since the USB-Implementer’s Forum (USB-IF) has yet to provide the tools for compliance testing, what should I do?”
The first step is to visit the USB-IF website and read the specification. Pay close attention to the design guidelines. The USB 3.0 specification has applied learning from other high-speed serial standards such as PCI Express and SATA, helping to evolve it into the state of the art in high-speed serial bus specifications. Another observation is that at 5 GT/s, USB finally is a high-speed serial bus with 10 times the raw data rate of the legacy standard.
Is USB 3.0 Like PCI Express?
The answer to this is yes and no. USB 3.0 is similar to PCI Express 2.0 in data rate and signaling. As shown in Figure 1, the signaling interface for USB 3.0 is a bidirectional full-duplex bus. 8B/10B encoded NRZ data is transmitted from the host to the device and vice versa at full data rate. The signaling is ~1 V differential CMOS with a common-mode bias of 500 mV at the transmitter. AC coupling is specified at the transmitter. However, this is where the similarities end.
Figure 1. USB 3.0 Physical Layer
In PCI Express, the 100-MHz reference clock (RefClk) is distributed from the host to the device so spread-spectrum clocking (SSC) of 0.5% of the signaling rate shares the same profile. With USB 3.0, each device has its own timing reference or RefClk and its own SSC profile.
In PCI Express, the connector is the interface between the host and device. Host and device channels typically are about 1″ to 2″ in length while the channel in USB 3.0 consists of a host channel that can be up to 12″ of FR4 and a 3-meter cable. In PCI Express 2.0, only transmitter and PLL LoopBW testing is a normative requirement for compliance.
Is USB 3.0 Like Serial ATA?
While USB 3.0 has the same signaling rate as PCI Express 2.0, like SATA, USB 3.0 is a cabled interface so the technical requirements are more similar to SATA than those of PCI Express. As in SATA, the host and device have their own local RefClks so the PLL clock recovery needs to be designed to account for differences in RefClk A and RefClk B profiles. Because of the long channel and the high data rate in USB 3.0, receiver testing becomes a normative requirement for compliance.
New Challenges With USB 3.0
Unlike PCI Express and SATA, the host channel can be quite long, up to 10″ to 12″. Accordingly, the USB controller chip can be quite a distance from the desired USB connector location on the host. For instance, many computers have USB connectors on the front and on the back of the system.
The combination of a long host channel and target cable lengths of up to 3 meters results in transmission channels with unprecedented length and complexity. Because of the channel complexities, the specification puts the responsibility on the chipset vendor to provide reference designs that meet very strict signaling requirements at the far end of a specified compliance channel. The eye diagram at the end of the channel in USB 3.0 is closed so a continuous time linear equalization (CTLE) function is applied to the signal to recover the eye for compliance measurements.
Transmitter Measurements at the Silicon
The specification defines measurement parameters for the transmitter at two test points. The transmitter test point, shown as TxH in Figure 1, is defined at the pads of the transmitter device and informative in nature.
Measurements can be made with a real-time oscilloscope after de-embedding the measurement channel from the measurement. The process for de-embed consists of developing S-parameters on the transmitter side of the channel and converting the S-parameters to a time-domain FIR filter applied to the measured waveform. S-parameters can be measured using a differential TDR oscilloscope with S-parameter extraction software or a VNA.
Either solution will provide a touchstone-formatted file. The touchstone file then can be imported into a real-time oscilloscope and processed using serial data link analysis (SDLA) software. The result is a waveform that can be compared to the parameters in Tables 6-8 through 6-11 of the USB 3.0 Rev1.0 specification. Figure 2 shows the result of the fixture de-embed and the resulting eye diagram at the pads of the transmitter.
Figure 2. Measurement Channel De-Embed and TxH Eye Diagram
Transmitter and Receiver Compliance Measurements at the Device Level
Whether you are designing a host, device, or reference design for a USB 3.0 controller chip, compliance testing needs to be performed. The normative parameters are defined at the far end of the channel, described in the specification as TP1 and shown as TP1H in Figure 1 and in Figures 6-14 and 6-18 of the Rev1.0 specification.
The compliance channel is defined as a reference cable and reference test channel. Physical cables and reference channels may be hard to come by in the early design stages. Fortunately, integrated software tools in the test equipment can be used to emulate both transmitter and receiver reference channels.
Figure 3 shows a connection diagram for testing transmitter and receiver compliance for a USB 3.0 transceiver.
Figure 3. Connection Diagram for Transmitter and Receiver Testing
Transmitter Compliance Testing Using Transmit Channel Emulation
Rather than acquiring the waveform at TP1, the transmitter compliance pattern, a scrambled D0.0 data pattern, is captured directly at the output of the DUT using the port test fixture. The record length corresponds to 1 million UIs from the port under test.
To emulate the waveform at the compliance point (TP1), the S-parameter files for the reference cable and the reference test channel are convolved into a single filter file. As expected, the eye diagram is closed when it is measured at TP1 (left eye diagram in Figure 4). Before analyzing the waveform for compliance, the specified CTLE filter from the specification must be applied.
Figure 4. Results of Emulated TP1 Compliance Test
After the CTLE function has been applied to the TP1 waveform, there is sufficient high-frequency amplitude to perform a compliance eye diagram test. The clock is recovered from the waveform using a golden PLL clock to data recovery (CDR). In the case of USB 3.0, the CDR function used is a 2nd order PLL with 0.7 damping factor with a corner frequency of 10 MHz.
Figure 4 shows the result of the transmitter compliance test. Along with the right eye diagram and mask, compliance measurements of eye height, total jitter (Tj), deterministic jitter (Dj), and random jitter (Rj) are displayed. The jitter methodology used in USB 3.0 is a Dual-Dirac model similar to that used in PCI Express. Limits are applied to the measurements per the USB 3.0 specification indicating a pass/fail result.
Receiver Compliance Testing Using Receive Channel Emulation
A distorted version of the scrambled D0.0 compliance pattern must be applied to the receiver port of the device. Traditionally, this is done by combining a signal from a BERT generator with multiple sources and fixtures to synthesize Rj, periodic jitter (Pj), inter-symbol interference (ISI), and SSC.
Combinations of Rj and Pj are synthesized per the jitter tolerance curve in the specification. In the case of USB 3.0, the jittered signal then is applied to TP1. The signal travels down the receive side of the channel and arrives at the input to the DUT with sufficient ISI to close the eye similar to the way the receiver would see a worst-case data signal in a real system.
An alternative method to applying the signal at TP1 is to use software tools on an arbitrary waveform generator (Arb) to create a signal with the proper Rj, Dj, ISI, and SSC for injection directly into the port of the DUT. Figure 5 shows an example of the software used to create the waveform directly. This technique allows you to create the proper signal at the receiver port without the need for a physical cable and receiver reference channel, similar to the way the transmitter was tested in the previous section.
Figure 5. Distorting the Receiver Signal Using Direct Synthesis on an Arb
Loopback BER Testing
Now that the specified distorted signal has been created at the receiver port, data errors at the receiver need to be counted. Receiver testing at the system level has been a challenge for other high-speed serial data standards.
Methodologies include the use of BERTs and frame error counters for error counting. These methods present issues with getting both devices into the loopback mode and dealing with SSC in the case of BERTs.
USB 3.0 provides a new option for receiver testing not found in other high-speed serial standards. Section 220.127.116.11 of the Rev1.0 specification requires implementation of a loopback BERT that allows an oscilloscope to easily de-code the error count from the loopback transmitter signal once the test is complete.
While the USB 3.0 receiver is in loopback, it must process BERT-ordered sets named BERT reset (BRST), BERT data (BDAT), and BERT error count (BERC). The test setup is the Arb/oscilloscope pair shown in Figure 3. The Arb starts by sending a repeating BRST pattern K28.5 K28.7. This sequence resets the error count register in the receiver.
Once the error count is reset, the repeating BDAT signal is sent to the receiver port. The BDAT sequence is equivalent to the scrambled D0.0 compliance pattern with a specified value of Rj and Dj. Once the impaired BDAT signal has been sent for the desired amount of time to achieve 10-12 BER compliance, typically 20 minutes, the Arb sends a BERC sequence which is a repeating K28.3 pattern. When the receiver sees the BERC sequence, the BERC signal is not looped back through the Tx path but replaced by a BERT Count (BCNT) sequence. BCNT consists of a K28.3 followed by symbol EC, which represents the error count detected during the test.
The loopback BERT built into the USB 3.0 Silicon allows the oscilloscope running protocol decode software to capture a single waveform of the BCNT sequence and decode the error count directly from the waveform, eliminating the need for any extra equipment.
To get a USB 3.0 device to market quickly, the use of transmitter and receiver channel emulation tools currently available on real-time oscilloscopes and Arbs will help you predict compliance of your USB 3.0 ports well before golden reference cables and hardware channels are widely available.
About the Author
Mike Engbretson works in the Technology Solutions Group at Tektronix. For several years, he has been actively involved in enabling high-speed serial development engineers with new measurement methodologies in industry standards including FibreChannel, InfiniBand, PCI Express, and most recently USB 3.0. Tektronix, 14150 S.W. Karl Braun Dr., Beaverton, OR 97077, 800-621-1966, e-mail: firstname.lastname@example.org
FOR MORE INFORMATION
on the USB 3.0 specification