This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TLK2711-SP: Incorrect Loss Of Signal status

Part Number: TLK2711-SP

Hi,

As I know, the LOS status output (RKxSB = High, RXD0-15 = High) when the incoming signal no longer has a sufficient voltage level.

But if you look at the waveform that I measured as below, RKxSB are high even though the RXP/N (Differential signal) is nearly 400mV and RXD15-0 are output h'FFFF.

That means that TLK2711-SP recognized the input data (h'A4A4) as LOS.

Strangely, this phenomenon occurs only in certain data patterns (h'A4A4, h'B5B5). It is all OK in other data patterns.

I did built-in self tests by combining PRBSEN with LOOPEN and it was OK . (RKLSB signal remained high.)

And I changed AC coupling capacitor value (10nF -> 1nF -> 100pF), but the result was same. (My setup configuration : TX FPGA (CML) -> TLK2711 (VML/AC Coupled)

Currently, I'm using 16EA TLK2711-SP device but only 2EA devices have this problem. I wonder if TLK2711-SP causes LOS when DC balanced valid input pattern is entered.

Best regards, 

  • Hi,

    If you increase the TLK VID from 400mVpp to say 500mVpp or 600mVpp, do you still observe LOS via RKLSB/RKMSB indicators with those specific patterns (e.g. h'A4A4, h'B5B5)?

    Thanks,

    Rodrigo Natal

    HSSC Applications Engineer 

  • Hi,
    Firstly, I typed the input data h'A4A4. But It was h'4A4A, I typed it wrong.
    According to your reply I increased the TLK VID from 400mV to 500mV~600mV. Then the LOS are not detected. 
    Can LOS observe even when the TLK VID is over 200mV and DC-balanced clock pattern (e.g. 01010101...) ?

    Best regards,

  • Hi,

    The min VID of 220mV per datasheet assumes Ethernet encoded data. If data is purely 1010 then LOS may be asserted.

    Thanks,

    Rodrigo Natal

  • If data is purely 1010 then LOS may be asserted.

    Hi, 
    When TX side transmit the data, then the data encoded with 8b/10b. Thus h'4A4A (D10.2), h'B5B5(D21.5) patterns may be encoded 010101_0101, 101010_1010 each. (It's like clock signal.)
    In this case, the TLK2711 device may assert LOS even in the VID is nearly 400mV and the patterns are 8b/10b encoded. 
    I don't get it why this can happen, so would you explain it more? 

    Thanks,

  • Hi,

    When a non-clock signal 8B/10B data pattern is transmitted there is both high-frequency and low frequency component to data. Thus if the Tx launch amplitude is 400mVppd then the Rx device will see a 400mVppd swing after the transmission media. If data is purely 1010 on the other hand there is only high frequency component to the data. Thus, the peak-to-peak amplitude observed after the transmission media at the Rx will be lower than 400mVpp due to insertion loss.

     Thanks,

    Rodrigo Natal

  • Hi,

    That means that when the peak-to-peak amplitude of transmitted data that is not encoded Ethernet protocol at the receiver is lower than 400mVpp, then TLK2711 device may be assert LOS even VID is above 200mVpp. To avoid this problem, receiver VID should be above 500mVpp at least. 
    If this recap is correct I'm wondering what is the minimum receiver VID margin. (450mVpp or 500mVpp or etc..)

    Thanks,

    Ethan 

  • Hi,

    I expect his LOS observation to be specific to the case when 1010 pattern is transmitted. I don't expect TLK LOS assertion for VID of 400mV if the data pattern is PRBS7, for example. I'd recommend to check that experimentally. 

    Based on your own test result if data is strictly 1010 then the source amplitude should be set to 500mV to avoid LOS assertion.

    Thanks,

    Rodrigo

  • Hi,

    I checked the PRBS7 data and the TLK didn't assert LOS. 

    I think I may consider to apply PRBS on TX side. (Does the Ethernet encoded data also use PRBS when transmitting data?)

    Thanks,

    Ethan

  • Ethernet encoded data will also contain long runs of 1s and 0s, so TLK LOS should not be asserted similar to PRBS7.

    Thanks,

    Rodrigo