TLK10232 problem with internal high speed test

Hello,

I would like to know what kind of loopback are you using to test the high speed side. We recommend perform a self-test the device through the loopback mode, then connect the system and optimize the link.
Every system is different, hence, the user needs to perform a "tuning" of the device according to AC losses, length of traces/cable, etc. Trying different settings for HS_SERDES_CONTROL_2 & HS_SERDES_CONTROL_3 to get the best combination of values for equalization.
As well, could you provide a block diagram of your system to find out the cause of the issues?

Best Regards,
Luis Omar Moran
High Speed Interface Apps
SWAT Team

Hello,

we cannot use the loopback function as we have a one way communication only.

We followed all you instructions in the  application note SLLA351 ‘Link optimization with TLK10232’ to bring up the system. We modified all parameters.

But still we could not get the high speed test to work (we did set up the Tx and Rx side to this test and checked the error register). All other tests pass.

When we use the TI demo board as Tx or Rx side and our board as opposite side, each board using its own clock, we see the problem. The link is either electrical or optical that doesn't make a difference. The problem disappears when we use the clock of the Ti demo board on our board as well. We are not sure if this happens because the clocks are synchronous then, or because your clock is 'nicer'. We tried to optimize our clock by changing the oscillator and better parameters of the CDCM but we could not see an influence. We reduced the clock to appr. 5GHz, same problem.

The setup is very simple: clock oscillator, CDCM, TLK 10232 then either electrical or optical link. For this test we did not apply any data input to the TLK.

Best regards

Juergen

 

Hi Juergen,

Is the clock oscillator that you are using meeting the TLK10232 specs for clocking and high speed side? Since, you mentioned the issue disappears when you use the clock from TI demo board.

Regards,

Luis

Hi Luis,

what specifically do you refer to?

We modified the clock oscillator (from an FPGA output to an oscillator) we programmed the jitter cleaner CDCM6208 in a way that the jitter is in the same range as it is in your reference design on the demo board.

But in all cases we didn't see any serious change.

Regards,

Juergen

Hi Luis,

meanwhile we received a second of your demo boards and connected them together, one as transmit board one as receive board.

After setting them up and adjusting the parameters, we see the same issue, all tests work fine except the high speed test.

So our conclusion is that this test works fine only when the clocks are synchronous.

Can you agree to this? 

Can we be sure that the high speed links link works fine, even if this test fails?

regards

Juergen

Hi Juergen,

Sorry for the delay. You are right, the clocks are synchronous, hence I agree that the high speed link works fine.

Regards,

Luis

Hi Omar

as mentioned we are using the 10G general propose mode with 4 lanes at the low side.

The question I have is

is the link fully transparent?

Lane A to lane A etc.

All 10b symbols are transferred without restrictions?

regards Juergen

Hello Jurgen,

Yes, the link is fully transparent. All 10b symbols are transferred without any restriction since the device needs 8b/10 coding to deserialize, sync and decode.

Regards,

Luis

Hello Luis,

the data we are sending over the talk based link includes 0x2AA in all 4 lanes for quite a while.

We have the impression that the talk doesn't like this as we see errors appearing.

Is this related to the 0x2AA data?

What is the longest sequence we can use before we get errors?

regards

Juergen

Hello Luis,

can you please answer my last question?

regards

Juergen