jitlim

When is RX testing not RX testing? Plus answers to other confusing USB Type-C RX testing questions

Blog Post created by jitlim Employee on Mar 1, 2017

In this blog, we will address some of the most confusing topics while RX testing a USB Type-C link.

  • When is RX testing not RX testing?
  • If I add the precise RX characteristics (CTLE, DFE, and clock recovery), doesn’t that qualify as a RX test?
  • I have always included CTLE and clock recovery during RX testing?
  • Why can’t I simply force loopback?

 

When is RX testing not RX testing?

Figure 1 is the USB 3.1 link where the Txp signal from the Host silicon goes thru the Type-C mated connector through the cable and ends up as Rxp in the Device silicon. There are numerous ways to characterize this signal:

  • Probing Txp close to the Host silicon
  • Testing at the Host connector with a Type-C fixture
  • Testing at the Device connector with a Type-C fixture
  • Probing Rxp close to the Device silicon
  • Testing at the Host connector and embedding the cable model
  • Testing at the Device connector and adding the Receiver Equalization and Clock Receiver

 

Very often, the last bullet is referred to as a RX test because it incorporates the various elements of a receiver implementation (CTLE, DFE, PLL BW, JTF).

 

However, it’s important to note that NONE of the above tests are true RX tests. They are all TX tests at different points in the link and have terms like TP2, TP3, TP2’’, and TP3EQ.

 

One clue this is not an RX test is that the analysis is performed using an oscilloscope.

 

When we perform proper RX testing, a BERT with a Pattern Generator (PG) and an Error Detector (ED)is used.

Figure 1. Channel Model courtesy USB-IF 

 

If I add the precise RX characteristics (CTLE, DFE, and clock recovery), doesn’t that qualify as a RX test?

When we perform a “RX test” with an oscilloscope by incorporating RX characteristics like equalization and clock recovery, we are simply emulating what a real receiver might be doing. If you review the spec, you will see words like “informative” CTLE, “reference” DFE, “golden” PLL, and “implementation specific” receiver training. This means that we can’t know, or duplicate the exact implementation in a RX design.

 

This also explains why you may have excellent results using a scope to perform a far-end TX test that includes RX parameters. However, it fails the RX test because the TX test does not capture the true performance of the RX implementation.

 

During RX testing, a pattern generator in the BERT presents a stressed jitter cocktail to the RX. This precisely calibrated worse case signal for USB 3.1 Gen 3 is show in Figure 2.

 

The other thing to note is the BERT specifically does NOT set any “informative” or “reference” RX parameters like equalization and clock recovery. The whole point is that during RX testing, a receiver trains, adapts and recovers data using its specific implementation just like in a live link.

Figure 2. RX calibration cocktail for USB 3.1 Gen 2

 

I have always included CTLE and clock recovery during RX testing

Figure 3 shows the test setup for performing USB 3.1 Gen 2 10G RX testing. The “RX In” signals going to the DUT receiver incorporate the jitter cocktail mentioned in Figure 2 and integrated in the pattern generator of the BERT.

 

The recovered data in the receiver is looped-back and re-transmitted at “TX Out” and goes to the BERT’s error detector. Very often this “TX Out” signal goes through a lossy channel making it difficult for the error detector to discern the digital content. Integrated into the error detector is clock recover circuitry and equalization to recover the “TX Out” signal. It is very important to note that the equalization and clock recovery integrated in the error detector is not standards specific. This capability is NOT a specification of USB 3.1 Gen 2 RX testing, but a technique to improve the signal quality going to the BERT’s ED.

Figure 3. BERT setup for USB 3.1 Gen 2 10G RX testing

Figure 3. BERT setup for USB 3.1 Gen 2 10G RX testing

 

Why can’t I simply force loopback?

 

The LTSSM (Link Training Status State Machine) for Gen 2 is significantly more complex than in Gen 1. Especially for early silicon without a port controller, it is much easier to force loopback then to go through all the link states.

 

The problem with this technique is the RX does not go through the crucial TSEQ (Training Sequence Receiver Equalization) for optimizing typical receiver equalization architectures.

 

Figure 4 shows the BERT LTSSM SW that dynamically interacts with a DUT receiver to transition through the various link states, then generates TSEQ, followed by the BER test. The SW can be setup to test the DUT for specific number of OS (Ordered Sets), or it can be setup to respond to the DUT’s LTSSM signaling and interactively train to loopback.

Figure 4. BERT Interactive Link Training Status State Machine

 

I hope this blog was helpful in illustrating the following:

  1. RX testing using an oscilloscope does not test a DUT RX at all.
  2. RX testing with a scope may pass while RX testing with a BERT may not.
  3. Testing with a BERT puts the RX in a state similar to operation in a live link.

Outcomes