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.

TS3DS10224: TS3DS10224: Eye-diagram test fail

Part Number: TS3DS10224
Other Parts Discussed in Thread: TMUX136

Hi team,

Let me clarify the issue, When we popular TS3DS10224.in the circuit. as you can see the eye diagram measurement result cannot pass the USB2.0 compliance test requirement. 

But, if we bypass the TS3DS10224 ( using external cable to short the traces on the PCB pads), the eye diagram can pass the USB2.0 compliance test requirement. That prove the PCB design is no problem. 

Questions.

1. What's the internal impedance (Z) of TS3DS10224 pins (both input and output pins)?

2. Is there other parts we can alternative TS3DS10224 to get better performance? pin to pin is better.

3. Any recommendation about TS3DS10224 at USB2.0 application? 

 

Muhsiu

  • Muhsui,


    1. What's the internal impedance (Z) of TS3DS10224 pins (both input and output pins)?

    This a passive device so there technically isn't a input/output impedance. Instead there is the effective resistance of the switch through the I/O path. This will depend on the configuration

    2. Is there other parts we can alternative TS3DS10224 to get better performance? pin to pin is better.



    There won't be a pin to pin TS3DS10224 device. Depending on what configuration and combinations you're trying to create, you could go with a more discrete and creative solution using something with a higher bandwidth like the TMUX136. The eye diagram looks like it's only in the <200MHz range so the TS3 device should be able to handle this. I've notice many questions on previous threads here but no real responses to some questions being asked.

    More specifically "Can you provide an eye diagram through the software and same test setup as the mux is going through but bypassing only the mux alone but still going through  the rest of the board?" I've only seen the eye diagrams from different softwares and would like to confirm the issue.

    Additionally it isn't clear if this suggestion : "definitely a lot of trace between the USB input and the TS3DS10224, so trying to reduce that trace length would be your best bet in trying to improve the device performance." It isn't clear if this was taken or an option.

    Last question from previous threads that may be of use here : "Have you tried testing basic communication through the device to see if the signal is actually being affected? What is the actual operating frequency you're looking to work with?"


    3. Any recommendation about TS3DS10224 at USB2.0 application? 


    TS3DS10224 should be able to support USB2.0 applications. The frequency is just 240MHz and the bandwidth of the device is 500MHz or 1.2GHz, depending on the configurations. It's interesting that there is a claim of an issue here but answering some questions from above may be helpful in getting a solution.


    A side note here, moving forward it may be easier to continue conversations on a single thread if it's a continuation from the same issue from here on out, instead of creating a new thread continuing conversation. It helps with organizing the debugging efforts.

    Thanks,
    Rami

  • Hi Rami:

    We have the slides that sum up all the results we got until now.

    20220912 USB2.0.pptx

    By the way, Our configuration is 1:4 in TS3DS10224's description

    Expect your suggestion.(If needed, Illustration would be better.)

    Thanks.

    For the previous discussion:

    1. Can you provide an eye diagram through the software and the same test setup as the mux is going through but bypassing only the mux alone but still going through the rest of the board?

    ==>I marked all the points that we tested. Although the bypassing test result was presented in a different format, It's still tested in the same instrument and setup.

    2. definitely a lot of trace between the USB input and the TS3DS10224, so trying to reduce that trace length would be your best bet in trying to improve the device performance.

    ==>Because of our current system configuration, We can't reduce trace length anymore. By the simulation result & bypassing the Mux test result. We think the layout channel is not the major reason for the distortion of the slew rate.

    3.TS3DS10224 should be able to support USB2.0 applications. The frequency is just 240MHz and the bandwidth of the device is 500MHz or 1.2GHz, depending on the configurations. It's interesting that there is a claim of an issue here but answering some questions from above may be helpful in getting a solution.

    ==>Because our configuration is 1:4, BW is up to  1.2 GHz. So It's available for USB2.0, right?

    4."Have you tried testing basic communication through the device to see if the signal is actually being affected? What is the actual operating frequency you're looking to work with?"

    ==>Could you describe this more specifically?

    5.https://e2e.ti.com/support/switches-multiplexers-group/switches-multiplexers---internal/f/switches-multiplexers---internal-forum/1111540/ts3ds10224-u2-uart-switching-with-ts3ds10224

    ==>We can't open the page that you provided, could you provide the title directly so we can search it?

    6. Was this layout revised since the issue was seen here? Looks like in the differential pairs, the length matching was fixed periodically through the inner trace. This may be affecting your signal as your shifting the noise differently. The length matching should be done at once at the end of the signal.

    ==>We've checked the P&N Mismatch and it is below 5mil.

  • WeiChen,

    Thanks for sending this over. It is curious that you're seeing this since the device should be able to handle this frequency. I wonder though if your overall system is just cutting it too close on the capacitive loading. Could you add an equivalent 9-10pF capacitor on the line. You could also add a 10ohm resistor as well in series to better replicate what the device should look closely like in the system. Then take a screen capture of the eye diagram persistence data.
    Then I ask that you remove the load and simply short the cable and provide a new screen capture of what you see there. I understand that the previous scope shot you have kept sending is the eye diagram from the shorted path, but I am asking to replicate a new eye diagram where the device is shorted to give us a base case now and to make sure we can duplicate it functioning when bypassing the mux.

    Thanks,
    Rami