TSB81BA3E: Are all ERRATA issues in SLLZ015C resolved with the TSB81BA3E silicon

Hello Johan,

We will look into this and get back to you.

Regards,
Yaser

Johan,

Could you point me towards the document you are referring too?

Hi Malik,

Attached the ERRATA.

Regards,

Johan

TITSB81BA3Errata.pdf

Johan,

This issue was fixed in TSB81BA3E.

Hi Malik,

Thanks for the response.

We have also confirmed on our side, the moment all 3 ports are active on the same PHY for a period of at least 12 hours, you are guaranteed to get bus resets. If you disable or loop disable any one of the ports on that same PHY, so that only 2 are active at a time, the bus resets totally disappear for 48 hour runs and longer. The moment you change the third port to 1394A, all bus resets also disappear. Any possible explanation what might be the cause of this, possibly still a timeout problem in a state machine of the PHY? According to us, the only solution is to have only 2 ports active on the same PHY at all times?

Regards,

Johan

Hi Malik,

We are using a FireWire Transceiver Line Interface Module (TM1062HUXB) and Equalizer (EQCO400T8) to extend the distance between nodes, might that have an influence on the timing the moment you use all three ports on a PHY?

Regards,
Johan

Hi Malik,

Is it possible to put us directly in contact with a TI technical specialist on this PHY?

We please need confirmation from TI that they also experience the same symptoms as explained below? Then we can be more assured that it is not something else we still are doing wrong and rather focus our time on finding ways to work around it. 

The moment all 3 ports are active on the same PHY for a period of at least 12 hours, you are guaranteed to get at least one bus reset. The more nodes you add to the network where all three ports are active, the more resets are detected. If you disable or loop disable any one of the ports on that same PHY, so that only 2 are active at a time, the bus resets totally disappear for 48 hour runs and longer. The moment you change the third port to 1394A, all bus resets also disappear.

Would really appreciate a clear answer on the above, so that we can move forward on the project.

Regards,

Johan

Hello Johan, this Richard Mourn with FlightWire Technology, I would like to understand the characteristic of the bus reset. Do you see a bus reset, nodes disappear for ~550 milli-seconds and re-appear? If so, this maybe noise/load issue causing a loss of synchronization. I've seen this issue on a poorly laid out board that worked fine with two ports connected but would periodically (one or two hours) have bus resets (disconnect) when three ports were connected.
Best Regards, Richard

Hi Richard,

Thanks for responding. Sorry for coming back only now, but for some unknown reason I was not notified that somebody replied to my query.

That is correct, we do see a sequence of bus resets directly after each other and then the bus fully recovers again between 530 and 590ms later. Please give more information on what was wrong on the layouts (cross talk, impedance mismatch, differential track length mismatch, reference planes?). Can we please get a confirmation that a re-spin of these PCB's, solved the above reset problem? Was it again tested for more than 12 hour runs, because that is typical the time we need to run the whole system before we experience the reset.

We have 3 different form factor LRU's with different layouts in the system (in total 30 nodes on the bus). All 3 give exactly the same results. You can have any 2 ports active continuously for more than 48 hours with no resets at all. Switching the active connections to the other ports on the same PHY's and run 48 hour tests with still no resets. This test gave us good confidence that the integrity of all 3 ports of the 30 PHY's are good and stable. We even introduced 30 meter commercial cables between ports to really push the links to there limits and got no resets.

The moment we make all 3 ports active of any one of the 30 PHY's, we get the above reset within 12 hour runs. You need to do more than 12 hours runs to be guaranteed of a reset.

Is it in anyway possible for you to configure any one of your products with all 3 ports active of the same PHY's with a FireSpy or any other monitoring equipment connected and run it for at least 48 hours monitoring for resets?

Kind Regards,
Johan

Hello Johan, it doesn't seem like E2E is working great right now ... I received a Answer Rejected note from E2E last night. Please contact me directly at support@flightwiretech.com.

I believe this issue is tied to the de-scrambler in the PHY losing synchronization with the incoming signal. This causes the PHY to misinterpret the incoming scrambled 8B10B symbols which in turn cause the bus resets  to happened. If a PHY receives four or more tightly spaced bus resets, it will disconnect and then go through the connection process (~550msec). This is good because the connection must be retrained to re-sync the de-scrambler to the incoming signal again.

We know this problem exists but unfortunately we don't know the exact root cause. It appears to be a noise related issue but the exact root cause of how the de-scrambler gets corrupted hasn't been determined.

Please contact me directly, perhaps there is an experiment we can run to provide our theory. 

Best Regards, Richard

Johan,

Are you still seeing issues with the TSB81BA3E in your system? Has the test proposed by Richard help shine light on what is happening in your system?