TLK2711-SP: ISSUE IN KCODE RECEIVING

Hi,

Can you clarify what the expected RX data is?  Is this designated by the "/" in the RX results (i.e. CB/F8)?

Thanks,

Drew

some time we got (RX8-15),(RX0-7)=CB,C3 
And some time we got (RX8-15),(RX0-7)=F8,F0
and we have one more question, we are using Kintex-7 410T FPGA module so it's confortable or not for encoding and decoding?
we are making loopback from differntial transmitter to receiver using of coaxial cable.
when transmit data that time we make high on ENABLE and LCKREFN.,

Hi,

I will look into this and get back to you with an update tomorrow.

Thanks,

Drew

Hi,

Thanks for your patience, I am still looking into this and will get back to you with an update soon.

Thanks,
Drew

sir , we are waiting for your reply. please give support to us.

sir , we are waiting for your reply. please give support to us.

Hi,

Sorry about the delay.  Would it be possible to share your schematic and initialization sequence for this part?  Also, are you transmitting k-code commas along with your data?  These help with data alignment to ensure the receiver is aligned to the data.

In regards to your question about the Kintex-7 410T FPGA module, as long as the setup/hold times of this part match the module and the module supports 8b/10b encoding/decoding, then it should work.

Thanks,

Drew

Dear sir,
Please find attached link of schematic.
optimizedsolutionpvtltd-my.sharepoint.com/.../EaHLFsHvxHpEj3-TUJJ7IEgBPU7b_hur0roc2kuQkXyRQw

and we are using TLK2711HFG/EM .

and we also try below sequence, but we can't received at receiver of same ic.

• K28.5 D5.6

•K28.5 D5.6

• K28.5 D11.5 (SOF optional and user definable)

• Dxx Dxx (Transmitted packet. Repeat for packet depth.)

• Dxx Dxx (Packet CRC if desired)

• K28.5 D5.6

• K28.5 D5.6

• K28.5 D11.5 (SOF optional)

Hi,

Thank you for sharing the schematic and transmission sequence.  I am reviewing these and will provide an update tomorrow.

I see that ENABLE and LCKREFN are pulled high in your schematic. Are there any conditions when you are driving these pins low?

Thanks,
Drew 

HI, 

Hi,

I have a couple of questions.

R & D said:

we have already done iteration with PRBSEN  as per datasheet and it's working fine .

Can you clarify what you mean by this? Do you mean that you were able to enable the PRBS generator and receive the PRBS signal fine? Are you receiving the PRBS signal through loopback or with another device.

R & D said:

and we also try below sequence, but we can't received at receiver of same ic.

In this situation, are you doing an external loopback configuration?

The sequence you tried seems to be correct, so it is definitely not obvious what is going wrong.  I am continuing to look into this issue.

I'm not sure if you have seen this, but I see that someone else with this part ran into issues because they were using too low of an input voltage.  This might be worth taking a look at:

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/864184/tlk2711-sp-received-data-error

Another item that comes to mind is can you confirm that your common mode voltages are appropriate for the differential signals?

Can you also verify that your TXCLK meets the jitter requirement?

Thanks,

Drew

Dear Drew,

We have asserted the PRBSEN pin high, hence as per EVM if  the PRBSPASS(RKLSB) pin indicating high means it is okay. 

We have checked this with two ways

1. With internal loopback LOOPEN and probe on TKLSB and there's no low level came in the RKLSB pin which looks IC's function is fine

2. To validate the serial part we have made LOOPEN high with SMA to SMA cable connected in loopback with same IC and  no low level came in the RKLSB pin which looks IC's function is fine with Serial data

For the common mode voltage on the differential line is 1.5V.

For oscillator we're using XLH536110.000000X - Renesas Oscillator Which has jitter performance of 1ps. 

Regards

Krunal

Hi Krunal,

Thanks for clarifying this!

R & D said:

2. To validate the serial part we have made LOOPEN high with SMA to SMA cable connected in loopback with same IC and  no low level came in the RKLSB pin which looks IC's function is fine with Serial data

I believe that if LOOPEN is high, then the data is looped back internally.  Have you conducted this test with LOOPEN low and also observed that RKLSB remains high?  If so, I would like to verify your problem statement since it has been some time since this thread was opened.

Problem: When looping back data from the differential transmitter to receiver using coax cable, there seem to be errors in the data transmission since you don't receive what was sent.  However, when using the PRBS generator and external loopback via coax cable (PRBSEN = HIGH, LOOPEN = LOW), RKLSB does not go LOW, indicating that a valid PRBS pattern is being received.

Can you please confirm that this is accurate.  Thanks for your patience on resolving this, this issue does not have an obvious solution.

Regards,

Drew

Dear Drew,
yes, you are right. LOOPEN is high than internally loopback , and this one working fine. As well at LOOPEN low with coax cable also it is giving the same results.

We'd like to share some more iteration pics of TX and RX channel,when we send below configuration.

In this configuration we only received FFFF.

1)  TX0 WAVEFORM

RX0 WAVEFORM

2) TX1 WAVEFORM

RX1 WAVEFORM

Regards,

Krunal

Hi Krunal,

Thanks for the scope captures!  I'll look into this and get back to you with an update tomorrow.

Thanks,

Drew

Hi Krunal,

Sorry about the delay.  Based on your response, it sounds like PRBS data can be transmitted and received with both internal and external loopback which is good.

Can you help me understand your system a little better?  For your initial post where you have are receiving inconsistent data, what is your system?  Is it something like FPGA --> TLK2711 --> TLK2711 --> FPGA.

It's also not clear to me why you are enabling TKLSB/TKMSB when you don't have valid k-codes on the tx pins.  I think that when TKLSB/TKMSB are high, you also want a valid k-code on the corresponding tx pins.

In order to ensure that rx data is properly aligned with the recovered clock, is it possible to put one of the RX pins and RXCLK on a scope together?  It would be valuable to see cases where you are getting correct data as well as incorrect data.

In the scope captures you provide, I notice that TX is being toggled high/low.  Are these pins being driven by the FPGA?  If so, does it always reset the pin to low before transmitting again, or is there something else going on here?

Also just to confirm, your clock frequency is 110Mhz, right?

Thanks,

Drew

Hi Drew, 

Drew Miller1 said:

what is your system?  Is it something like FPGA --> TLK2711 --> TLK2711 --> FPGA.

Yes, this is true. 

Drew Miller1 said:

It's also not clear to me why you are enabling TKLSB/TKMSB when you don't have valid k-codes on the tx pins. 

Sometimes we get data when we want to keep TKLSB/TKMSB at a low level, 

Sometimes random data is generated, at which point RKLSB / RSMSB toggles high and low.

Drew Miller1 said:

In order to ensure that rx data is properly aligned with the recovered clock, is it possible to put one of the RX pins and RXCLK on a scope together

Yes, i will send you. 

Drew Miller1 said:

In the scope captures you provide, I notice that TX is being toggled high/low.  Are these pins being driven by the FPGA?  If so, does it always reset the pin to low before transmitting again, or is there something else going on here?

Yes,it resets every time. 

Drew Miller1 said:

Also just to confirm, your clock frequency is 110Mhz, right?

Yes, Clock frequency is 110MHz.

Regards,

Krunal

We're finding the GTX clock noise is getting added to power supply whenever we supply clock to IC. Because of this noise we've observed it is getting reflected to random noise in some of the Tx and Rx pins

The earlier version of IC that we've used was having two separate grounds GND and GNDA whereas this has single.

Earlier IC which we have worked with 

Also this version as there's written it can support TX clock till 3.6V we have used 3.3V crystal. Please can you confirm, is that fine?

Retards, 

Krunal

Hi,

A 3.3V crystal should be fine based on the datasheet.  Does this seem to be causing the issue you are having?

R & D said:

Sometimes random data is generated, at which point RKLSB / RSMSB toggles high and low.

If you are not transmitting k-codes, then these pins definitely should not be toggling.

Thanks,

Drew

Hi,
We are using XLH536110.000000X crystal oscillator for 110MHz.

Drew Miller1 said:

If you are not transmitting k-codes, then these pins definitely should not be toggling.

Yes, Right..... But there was occur.

Regards,
Krunal

Hi, Drew

Can you help us with whether the separation of ground and supply for high speed and parallel data lines play a significant role in power integrity for this IC?

For your reference I'm attaching links of both versions.

https://www.tij.co.jp/jp/lit/ds/slls501/slls501.pdf

https://www.ti.com/lit/ds/symlink/tlk2711-sp.pdf?HQS=dis-dk-null-digikeymode-dsf-pf-null-wwe&ts=1637658879417&ref_url=https%253A%252F%252Fwww.ti.com%252Fgeneral%252Fdocs%252Fsuppproductinfo.tsp%253FdistId%253D10%2526gotoUrl%253Dhttps%253A%252F%252Fwww.ti.com%252Flit%252Fgpn%252Ftlk2711-sp

Regards,
krunal

Hi Drew,

We are waiting for your answer.
Please , support to us.

Regards, 
Krunal

Hi Drew,
we have attached some scope result of RXCLK.


(1)  when data was not getting changed at tx that time RXCLK result.
 

(2)  when data was put on TX including comma characters, by that time received clock.

Regards,
Krunal

Hi Krunal,

Thanks for your patience.  I was out of office last week due to the holidays.

If you still have concerns about the GTX clock noise on the power supply, would it be possible for you to share your PCB layout?

Thanks for getting captures of RXCLK.  The 2nd capture when data is sent on TX looks really strange.  Was this scope capture taken in a loopback configuration?  If so, was it internal or external loopback?

How does RXCLK look when using the build in PRBS generator?

Thanks,

Drew

Hi Drew,

Drew Miller1 said:

If you still have concerns about the GTX clock noise on the power supply

Now , GTX clock working fine and we getting pure power supply.

Drew Miller1 said:

Was this scope capture taken in a loopback configuration?  If so, was it internal or external loopback?

Yes, it was on internal loopback.

Drew Miller1 said:

How does RXCLK look when using the build in PRBS generator?

That time makes proper RXCLK .

Regards,
Krunal

Hi Krunal,

Thanks for the clarification.

Your RXCLK seems really strange.  It seems that there is some sort of correlation with the data you are sending and the RXCLK signal.  Is RXCLK good if you send PRBS data through an external loopback?

I am wondering if for some reason that clock is not tracking the data signal correctly.  If you toggle LCKREFN low, the RXCLK should lock to TXCLK.  Can you confirm that the RXCLK clock signal is good when this is the case?  After this, set LCKREFN high and see what happens to RXCLK.  If possible, maybe trigger your scope on the rising edge of LCKREFN while probing RXCLK.

Here is another thing to test:

If you just send repeated K28.5 comma and no other data, how does RXCLK look?  Please include a scope capture if applicable.

Thanks,

Drew