TLK2711-SP: Incorrect data at received data bus

Keng, I can help.

It is difficult to know what exactly is wrong.  

However, when you receive bad data, the TLK2711 reports a K0.0 for both bytes.   This is indicative of an error on both bytes.

From datasheet page 17:

An error detected on either byte, including K codes not in Table 4, causes that byte only to indicate a K0.0 code on the RKxSB and associated data pins, where K0.0 is known to be an invalid 8-bit/10-bit code.

Since you are seeing this on both bytes, then both MSB and LSB are incorrect.   This seems a little unusual and likely represents bad serial data.

I suspect that you are not meeting clock input requirements.

What is supplying your input clock?   Is it low jitter? What frequency?

Does the link perform error free with PRBS enabled?   You can set PRBSEN, and then monitor RKLSB.  If RKLSB is not static high, then PRBS is failing.

Regards,

Wade

Hi Wade,

The link perform error free with PRBS enabled.
1. I'm suspecting the clock too.
currently my clock (125MHz) comes from the Xilinx FPGA.
Is this clock good enough?
My data comes from the FPGA too.
What is the best way to provide the clock?

2. Even when the 8 data is toggling, only the first data after the 2 inverting idles is incorrect.
The rest are correct. In your opinion, is this due to clock issue?

Thank you.

A clock sourced from an FPGA will not meet the input conditions defined in the datasheet.  The datasheet shows 40ps pk-pk jitter maximum.   This is pretty stringent specification.  Additionally, it can be relaxed somewhat if the jitter is not located in peaking region of the jitter transfer function.   Please see this post:

It discusses requirements and options.  It also points to another post regarding relaxations that may be possible from the 40ps specification.

Since you are testing in the lab, you can feed your FPGA clock to a reference input of a clock generator, then the clock gen can generate clean clock to TLK2711.  However, you will need to set the proper delays so setup and holds are maintained.  I use an agilent 8133A to perform this.  It has delay ability and provides reasonably low jitter clock.

I am not certain of the cause of your error.  It is either the clock jitter, or possibly data is not clocked properly and during the transition and an invalid K code is attempted to be transmitted.  One way to test this, is keep same data on the transmitter, and only de-assert the TKMSB. 

Do you get same results if you loop back externally?   If you have proper equipment, you could capture the transmitted serial stream, and we can analyze exactly what the receiver is seeing.   You can also examine the eye diagram to see have much jitter is getting on the transmitted stream.

However, cleaning up the clock is critical for low error rate link.

Regards,

Wade

KGY,
Have you identified your issues as of yet?
If so, please click this resolved my issue to close out the post.

Thanks,
Wade