This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VH-Q1: USB3.0 Physical Layer Compliance Test Scripts

Part Number: TDA4VH-Q1
Other Parts Discussed in Thread: TDA4VH

Hi TI Experts,

Customer is working on TDA4VH SDK9.1.

I have previously asked a related question in the below thread.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1275095/tda4vh-q1-usb2-0-and-usb3-0-physical-layer-compliance-test-scripts

We have made it work on USB2.0 with the below code commands.

Force to output Test Packet for Eye Diagram Test
devmem2 0x06010484 w 0x40000000

Force to output J_STATE
devmem2 0x06010480 w 0x000000A0

Force to output K_STATE
devmem2 0x06010080 w 0x00000004


Force to output SE0 (host) / NAK(device)
devmem2 0x06010484 w 0x30000000

We previously thought for the USB3.0, the code command should be the same, so we close the thread.

However, recently when we look at the details of the above register address, we found that the description is just for USB2.0, but not for the USB3.0.

Also, we could not find the register address related to the CP0 & CP1 shown below in the USB3.0 compliance pattern sequence.

Could you help to provide the corresponding commands needed to test the following features in USB3.0 on TDA4VH please?

1: Force to output Test Packet for Eye Diagram Test

2: Force to output J_STATE

3: Force to output K_STATE

4: Force to output SE0 (host) / NAK(device)

5: CP0 & CP1 Test (any command needed to switch from CP0 to CP1 test?)

We have found some general test steps of USB3.0 standard shown below for CP0 & CP1 Test.

May I know is there a suggested configuration or command that could make TDA4VH enable USB3.0 Compliance mode?

The reason to ask is that, according to the USB3.0 standard it mentions that, as a host, the compliance mode is disabled by default, and it needs SOC to enable it. 

Many Thanks!

Kevin

  • Kevin,

    The commands for the USB2.0 test mode are below on 06010484h bits 31:28.

    001: Test J_STATE  
    010: Test K_STATE  
    011: Test SE0_NAK  
    100:: Test Packet  
    101: Test FORCE_ENABLE  
              

    For USB3.0, I had validated using the serdes_diag code and not on the EVM or using the Linux commands.

    For LFPS, I used the serdes diag to enable the TX_LFPS_EN bit and capture the output on the scope.

    CP1 is a clock at the Nyquist frequency (2.5GHz); so a continuous 0/1 pattern is to be sent out.

    For CP0, I used a pattern generator( BERT) which sent out the CP0 pattern into the device and loopback out onto the TX pins and into the scope for validating.

  • Hi Shreyas,

    Really thanks for your information!

    Customer has reached to the USB3.0 Compliance Testing vendor today for testing CP0 & CP1 on Tx of our TDA4VH. However, we did not get the results because there is no BERT available.

    We have studied on the below link for a general CP0 & CP1 testing.

    https://www.teledynelecroy.com/resources/details.aspx?doctypeid=2&mseries=584

    It seems that there are two different ways to test CP0 & CP1 described below.

    1: Using Ping.LFPS to the Rx port of the DUT to toggle the compliance patterns. (This method means that our SoC should generate and send out the CP0 through the Tx by it self without BERT) This method is the suggested way by the vendor today, because they do not have the BERT.

    2: Using the BERT to generate the patterns on Rx and loopback to Tx then send to the scope. I think this method is just as you suggested.

    Based on the above understanding, may I have your support for the below 4 questions please?

    1: Is there a way that we could use the method one (without BERT) to toggle the patterns on TDA4VH to test CP0 & CP1? If so, any guidance would be very appreciated.

    2: As BERT is quite expensive, if method 1 is not supported, do we have any other methods that could test CP0 & CP1 without BERT?

    3: If we have to use BERT for CP0 testing, it seems we need make TDA4VH in loopback mode. May I know is it default in loopback mode already or we need some configurations? Also, does CP1 testing also need a BERT like CP0 testing?

    4: In the above open resources, it mentions that in loopback mode there are usually skips present in the data that may cause the variations in the results when compared to Ping.LFPS mode. What do you think of this point, do you think using BERT in loopback mode is sufficient for CP0 & CP1 testing?

    Thanks again for your strong support!

    Kind Regards,

    Kevin

  • Kevin,

    The idea about the BERT was to provide the pattern into the device while it is in loopback (RX to TX). Instead of the BERT, you could also use a pattern generator or AWG to send the CP0 pattern. CP1 can be provided from the device as I had mentioned earlier post using a 1-0-1-0 pattern in the SERDES diag code (set to SERDES_UDD and configuring the UDD pattern as below).

    I haven't done the 1st method while validating and hence I am unsure about the process.