TUSB8041: Signal integrity problem

Hi Carmen,

Can you share the eye?  How long is the PCB trace?  What is the current R1 value?

There is no ability to impact the eye via SW.

Regards,

JMMN

Hi,

attached you can find the eye measurement. I have also attached a second document showing variations of R1 value and their impact.

PCB trace length is about 38 mm. And the current R1 value is 9k53 Ohm.

Colibri_CWL6_USB-2_X1100-USB1-connector.pdf

Colibri_CWL6_USB-2_R1-tuning-checks.pdf

Regards,
Carmen

Carmen:

     From 1st report, eye diagram looks ok, it failed Sync field length test, not eye diagram.

Regards

Brian

What is the difference between the test runs?  As Brian noted, some of the failures are due to SYNC field and EOP width which are expected changes if you are sending a test packet through a hub.  Make sure you are configuring the system so that the hub is generating the test packets, not passing test packets sent by host or device.

Regards,

JMMN

Yes correct, the eye diagram is not directly a fail. But it also does not look very nice. The rising edge is close to a fail and could be improved. Or is this a typical behaviour/eye diagram for the TUSB8041?

Since the signal integrity measurements were done externally, I will have to clarify how it was measured.
Just for my understanding: in normal operation the hub is used to pass data from the host or device. Wouldn't it make sense to then send the test packets by host/device?

Hi,
Your issue is being assigned to the appropriate engineer. Due to the US Holiday there may be a delay in response to your post. We apologize for any inconvenience.

Can you share the difference between the test runs?  The expected TUSB8041 behavior is showing in figures 18-22 of the datasheet, but there may be more attenuation depending on trace length / impedance.

You can send the test packets from the host or the device and pass them through the hub, but per the USB spec it will impact the number of SYNC bits and the EOP width of the test packet - your test tool should be configured so that it is aware that you are using a test packet that has been repeated by a hub or it the test tool may mark a failure based on SYNC bits or EOP width.

Regards,

JMMN

Hi,

sorry for my delayed answer due to the christmas holidays.

Basically, the test run in the first document (X1100-USB1-connector) and the first 2 trials in the other document are the same. The document called ...R1-tuning-checks then includes some more runs with different values for R1. This is described in the comment on the very first page.

Our goal is to get some more closer to the eye diagrams, that are shown in the datasheet.

Regards,
Carmen 

Hi,

thank you for these information.

Our tests were likely done with sending the test packets from the host and the hub was only passing data. 
So for only testing the functionality of the hub it clearly makes sense to generate the test packet by the hub. But for analyzing our USB interface in total it probably makes more sense to send the data from the host, right? Since this is the standard usecase?

I have once more checked our design and saw that the traces between host and hub are quite long (210 mm). However, the traces from hub to connector are as short as described above. How does the hub pass the data? Is there some kind of signal processing that could tranform "not so good" input signals to "better" output signals (from a signal integrity point of view)?

Regards,
Carmen

Hi Carmen,

The hub has transceivers on each port, it doesn't pass through packets in the analog sense like a switch, it completely retimes  / recreates them.  The only differences in the test results between a test packet that is generated by the hub and the test packet passed through the hub is the SYNC bits and EOP width differences.  These differences won't change the eye diagram but they will cause failures in the eye processing software since they are unexpected.  If the PCB trace on the downstream port is very short, I would expect the eye to be more open.  What is the impedance on the downstream port?  What does the test fixture look like?

Regards,

JMMN

Hi,

thank you for this explanation. Then we really should try to let the hub send the data. How can we configure the hub to do that? I couldn't find any information in the datasheet or other documents on your website. Can you provide us an instruction?

The signal was routed to match 90 Ohms. However, there is an Common-Mode-Filter between the hub and connector. Can this cause the problems? We are using a ECMF02-2AMX6 by STMicroelectronics.

Our test fixture should be fine, since for other USB interfaces we get really good eye diagrams.

Regards,
Carmen

Hi Carmen,

What tool are you using to have the host generate test packets?  Is it the USB-IF XHSETT tool?  If so, there is a hub tab that you can select and set which hub port sends the test packets.  Since the USB 2.0 test procedures are all mandated by the USB-IF, TI does not have specific documentation on how to run the hub tests but if you tell me which tools you are using I can help support it.

You could try removing one of the filters for the test, but I would assume since it is designed for USB 2.0 it would not have a significant impact.

Regards,

JMMN

Hi,

since we are not sure anymore which settings were used, we will repeat the measurements in the next weeks. And we will also try removing the filters for a test.

I would guess that we will then find the reason behind our signal integrity issues. If I know for sure, I would finally resolve the ticket. Thank you very much for your help!

Regards,
Carmen