USB 3.1 TX/RX Testing: Pitfalls that prevent Compliance Certification

Blog Post created by jitlim Employee on Jan 11, 2017

As USB3.1 Gen 2 comes into the mainstream, we have learned a lot from testing early silicon and systems. In this blog, we will discuss common pitfalls that prevent certification, and steps you can take to ensure your product gets certified.


The first pitfall, is not getting and implementing the latest updates to the USB 3.1 specification.


When you download the USB 3.1 spec from the USB-IF, the spec is in the root directory show in Figure 1. However, the spec does not include updates that were added after the spec was released. These spec updates are in the ECN (Engineering Change Notice) folder and the PHY (Physical) ECN sub-folder, both shown in Figure 1.


Figure 1. USB 3.1 Specifications directory structure.


You should always compliance test using the latest ECNs, and if your product is not designed to the latest ECN, it will fail compliance. Let us review some of the most common ECNs that were not implemented, or were implemented incorrectly.

  • Various TXEQ ECNs: These added the requirement and spec for both TX Preshoot and De-emphasis. Also, the addition of CP13-CP16 compliance patterns to enable measurement of Preshoot and De-emphasis. Silicon and systems that do not implement this ECN will fail the normative/required Preshoot/De-emphasis compliance test. In addition, they will also fail inter-op.
  • Various SCD ECNs: Clarified the requirements for SCD1/SCD2 operation for 10G links and 10G ports when connected to 5G legacy products. Not implementing this ECN will cause failure of the SCD1/SCD2 TX compliance tests and also fail the RX loopback training sequence. The USB link will also not train to the full 10G capability.
  • SKP OS ECN: Some systems cannot handle the new ECN requirement of inserting SKP OS every 40 blocks with 20 SKP symbols in each SKP OS and will fail the RX JTOL test. The original spec requirement was for inserting SK POS every 22 blocks with 12 SKP symbols in each SKP OS.
  • SSP ping.LFPS tRepeat Requirement ECN: If not implemented correctly, your product will not transition through the various compliance patterns CP0-CP16 and will fail the TX compliance test.
  • Reference Clock Reqs ECN: Limits crystal-less devices to specific configurations and requires a compliant input signal to pass the TX compliance test.
  • Various Loss Budget ECNs: Defines the loss budget for the Host, Cable Assembly, and Device. An incorrect implementation will result in losses that exceed spec or expensive designs that far exceed the requirements.
  • Various RJ ECNs: Clarifies the new requirements for RJ, updates the RJ pk-pk spec, and specifies the RJ measurement point to be near-end. Not adhering to the latest ECNs will result in RJ values and/or measured RJ values that fail spec.

If you get the spec and the ECNs correct, the next pitfall comes from incorrectly integrating UBS3.1 with Type-C and Alternate Mode in your designs.


In a legacy Std A–Std B implementation, there is only one USB 3.1 signal that goes from the Host to the Device. Things get more complicated with a typical Type-C implementation shown in Figure 2.


Figure 2. Type-C implementation challenges (courtesy USB-IF)

To allow for cable flipping and swapping, the USB 3.1 signal has to be routed on both the TX1/RX1 and TX2/RX2 sides. If your design uses one USB3.1 output, there needs to be a switch/mux to route the signal to either the CC1 or CC2 sides shown on the right in Figure 2. The addition of a mux and additional routing will add IL (Insertion Loss) to your link. Hence, an implementation that worked in a Std A/Std B configuration may fail compliance in a Type-C design due to these additional SI (Signal Integrity) issues.


If you are implementing a Type-C Host, there is a high likelihood that in addition to USB, you will need to implement Alternate Modes like DisplayPort, Thunderbolt, MHL, or HDMI. In that case, you will need yet another switch to route the correct Alternate Mode signal in addition to the CC1/CC2 switch.



Each switch can add ~1dB of loss. So, if you implement a Type-C switch plus an Alternate Mode switch, that’s ~2dB of loss. And at 10G, you can only route perhaps 3 inches before you run into SI issues.


Here are of the techniques you could use to compensate for these losses:

  • Using low loss PCB materials can halve your IL and add length to your traces. You do need to watch out for thin PCB materials, via stubs, and cross-talk issues.
  • Internal micro-coax cables can significantly reduce IL but the trade-off here is cost and real-estate for the connectors.
  • Repeaters like redrivers and retimers are common candidates for improving SI. Redrivers are simpler and less expensive to implement. Retimers are more complex but have much better performance.
  • The TX EQ is defined and specifically tested and cannot be tweaked. Although there is a standards definition for the RX EQ, it is tested only indirectly as part of the RX test. Hence, you can develop custom RX EQ with cost and power consumptionbeing the negatives.
  • Finally, there continues to be a roll-out of integrated silicon that integrates some or all of the Type-C ecosystem components – USB, DP, Thunderbolt, switches, retimers, redrivers, and PD. This is shown on the left side in Figure 2.


Compliance certification is a stressful, expensive, and lengthy task. And failing compliance is even more expensive due to redesigns and missing product shipping milestones. You do not want to send a product for compliance certification until you are 100% sure it will pass.


With this blog, I hope you were able to understand and navigate some of the more difficult issues with your Type-C designs. And use some of the approaches mentioned here to achieve compliance certification for your products.