TLK2711-SP: TLK2711 data transfer

Request noted. Will reply soon.

Thanks,

Rodrigo Natal

HSSC Applications Engineer

first_file_of_source.zipHi Sir,

I have attached the files that we are using for testing. if it exceeds the 8B/10B encoding requirement. How to resolve the issue?

Regards,

Anuradha C

Hi Sir,

I am waiting for your suggestion. Can you please reply back?

Anuradha,

I do not support this device, but am very familiar with it.

Can you describe the protocol you are using?   How often do you send the comma?  Any other K codes used? What does your comma look like (inverting pair Only one parity of the comma is valid?).  I do not know how to decode your .bin file.

Simply describe protocol and data similar to the app note description.

Presumably this is TLK2711 to TLK2711 transfer?  or is source or destination different?

Regards,

Wade 

Hi Sir,

We are using TLK2711-SP at both receiving and transmitting end.

The protocol used is:

Anuradha,

Can you show the data for the K28.5/D5.6 in your file?     Ie, break out the relevant (comma) sections and add comment?

I assume this file is only the raw 8B data. (how is K code identified to transmitting FPGA to assert TKLSB?)

Does receiving FPGA see the proper decoding of the framing header K28.5 and D5.6?  

Regards,

Wade

Hi Sir,

I am not capturing the K code in the file. I am only taking the valid data.

In Receiving section i can see the proper K28.5 and D5.6. 

Regards,

Anuradha C

Anuradha,

I am uncertain what would cause behavior you are seeing.   There should not be significant difference with all zeros or all ones since they are getting 8B/10B encoded.   So, this does not make sense.   Unless somehow an accidental K code is transmitted that can be seen as a comma causing the receiver to re-byte align incorrectly.  

If you have received data with K-codes, possibly this can be determined by seeing where the error first occurs.

Other potential causes:

Signal integrity of serial lines: What does eye diagram look like at RX?  Does it meet requirements?

Clocking:

clock ppm matching, clock jitter.    Clock sources for RX and TX need to meet 40ps total jitter.

Regards,

Wade

Hi Sir,

If i continuously transfer zero or one. there is no issue. If i transfer data appended with few zero's inbetween the data is causing the error. sometimes If i transfer zero, I am getting 3C in the place of zero's and some times junk data.

Regards,

Anuradha C

Anuradha,

You indicate you see a 3C as part of data.

I suspect this may be a K28.1, and it contains a comma and not D28.1.   You must insure that the TKMSB or TKLSB is not asserted as part of the data transmission (only when sending the comma).   Can you confirm this?

If this is not the issue, then only other thing I can offer is to validate the signal integrity, clocks, and verify eye diagram.

You might try to connect with a protocol analyzer/BERT that can decode the 10B data.   This will help understand if correct data is being transmitted, or if it is getting corrupted.  Or, if a K code is transmitted when not expected.

If you are using K codes for other data than sending comma, you must be very careful to insure it does not contain a comma.  There are several K codes that have the comma embedded. (K28.1, K28.5, and K28.7)

Rodrigo may have other ideas to debug.

Regards,

Wade

I just took a quick look at 3C, and its RD- parity 10B value is a single bit different than a D0.0.  So, if a bit is lost, it could turn a D0.0 into a D28.1.

The PLL has the ability to track out a total of 400+ parts per million of clock mismatch.  However, some of that is used for jitter budget.

The specification calls for clock matching of +/-100ppm for each the TX and RX.   Can you confirm clock specifications meet this requirement?

Please evaluate eye diagram for signal integrity at RX as well as clock jitter on both RX and TX.

Does PRBS transmission work error free?  This should be more worse case for SI than 10B encoded.

Regards,

Wade

Hi Sir,

We tested by changing the TLK2711 clock to 100Mhz. whatever the data, we transfer we are getting fine. but if i use the 110 MHZ clock for serializer, the data i am getting is wrong whenever the data files inbetween contain some zeros. when data is shifting from zero to some value. there I am getting the missing zeros. How to resolve this issue?

Regards,

Anuradha C

Anuradha,

Can you shed some details on your system?   What clocking?   From lab equipment or oscillator?  What media?

How did you change clocking?  Are the clocks matched to within +/-100ppm?  (requires 10MHz reference clock for lab equipment)

Have you compiled answers for earlier questions on clock jitter, and signal integrity (eye diagrams),  does PRBS mode work ...?

There are really very few details to help you here.

The data being sent "should" be irrelevant, other than the protocol information utilizing K code.  Ie, the periodic double inverting comma with K 28.5 D5.6.

Regards,

Wade