• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 33 subscribers
  • Views 1218 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Acceptable comma command for TLK2711-SP

Ryuuichi machida
Guru 12620 points
Part Number: TLK2711-SP

Hello,

Let me confirm about below.
From following informations, at first I understood that comma commmand should be sent K28.5/D5.6 twice.

1. The 8-bit/10-bit encoding contains a character called the comma (b0011111 or b1100000), which is used by the comma-detect circuit on the TLK2711-SP to align the received serial data back to its original byte
boundary. The decoder detects the comma, generating a synchronization signal aligning the data to their 10-bit boundaries for decoding; the comma is mapped into the LSB.

2. And also, theory of 8B/10B(From IEEE802.3 Section 3), idle of order_set is defined as K28.5/D5.6.
3. This implies that the user must send the 0011111 comma. However, a single K28.5 may not generate this comma, as the current running disparity is not deterministic. This is
solved by sending two inverting (or correcting) idles back to back. An inverting IDLE is two words that taken as a whole will cause the running disparity to flip. So two back-to-back inverting idles will ensure
that one of them will be the correct decoding of the K28.5. The inverting idle is defined as a /K28.5/D5.6/.
There are other data values that will cause an inversion when paired with the K28.5.

However, from following sentence of "www.ti.com/.../sgla001a.pdf", I think that "D5.6" is not mandatory.
(I believe that It is OK to use data or K code which have same number of "0" and "1".)

One of my customer use K23.7(it seems that this is used for PCIexpress) instead of D5.6.
I would like you to confirm whether other data can accepatable for MSB(15:8) of comma command.

Best Regards,

 

  • 0
    TI__Mastermind 19235 points

    Hi,

    Related to:

    However, from following sentence of "www.ti.com/.../sgla001a.pdf", I think that "D5.6" is not mandatory.
    (I believe that It is OK to use data or K code which have same number of "0" and "1".)

    One of my customer use K23.7(it seems that this is used for PCIexpress) instead of D5.6.
    I would like you to confirm whether other data can accepatable for MSB(15:8) of comma command

     

    The data case above should be acceptable for the TLK2711-SP based link.

    Regards,

    Rodrigo Natal

    HSSC Applications Engineer

  • 0 in reply to Rodrigo Natal
    Guru 12620 points

    Hello Rodrigo-san,

    Let me confirm about below which is described in section 4 of http://www.ti.com/jp/lit/an/sgla001a/sgla001a.pdf.

    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)

    According to above, it seems that K28.5 is for LSB(7:0) and D5.6 is for MSB(15:8).

    Is my understanding correct ?

    If so, could you please tell me how TLK2711 can understand comma command ?

    Because, according to block diagram of datasheet, comma detect circuit is implemented for both MSB and LSB.

    So, if user send following command under following understanding, each comma detect circuit will receive as shown below.

    Comma command understanding :

    K28.5 D5.6
    K28.5 D5.6

    (K28.5 for LSB, D5.6 for MSB)

    Comma detect circuit.

    MSB side will receive : Twice of D5.6

    LSB side will receive : Twice of K28.5

    I understood the meaning of "K28.5 -> D5.6 -> K28.5 -> D5.6" is to ensure running disparity = -1.

    So, in fact, user need to send as shown below.

    K28.5 K28.5

    D5.6 D5.6

    Could you please confirm about above my question and send me answer ?

     Best Regards,

  • 0 in reply to Ryuuichi machida
    TI__Guru 62930 points

    Ryuuichi,

    I can easily answer this.

    Comma always belongs on the LSB.   If it is detected on the MSB, it will re-align the output to byte align it to the new LSB.

    The reason for comma detection on both, is that it is dealing with 2 words at a time.   So, the comma detect block is really one block working on the full 20bit word prior to defining the byte boundary between them.  That is accomplished when a comma is detected, then it is aligned as the LSB.

    Hopefully this is clear.  

    Sending K28.5 K28.5  D5.6 D5.6  is not appropriate.

    If this answers your question, please click "This Resolved My Issue"
    Regards,
    Wade

  • 0 in reply to Wade Vonbergen
    Guru 12620 points

    Hello Wade-san and Rodrigo-san,

    Thank you for your reply.

    1. Yes, as a result of out check, we found error in this code.

    >Sending K28.5 K28.5  D5.6 D5.6  is not appropriate.

    2. Now, we have following issue.

    When user use comma command as shown two pattern.

    2-1. K28.5 D23.7

    2-2. K28.5 K23.7

    From previous thread Rodrigo-san said "The data case above should be acceptable for the TLK2711-SP based link." for "K23.7".

    Therefore, I understood we can use both command as comma. However, according to our experiment, behavior is different.

    * We tried following two case.

    Case 1 : PC1 -> TLK2711 board 1 -> TLK2711 board 2 -> PC2

    Case 1-1. When send ping command from PC1 to PC2, both comma usecase("K28.5 D23.7"(2-1) and "K28.5 K23.7"(2-2)) work correctly.

    Case 1-2. When perform small size(approx 1M) transfer from PC1 to PC2, both comma usecase("K28.5 D23.7" and "K28.5 K23.7") work correctly.

    Case 1-3. However, when perform big size(approx 1G) transfer from PC1 to PC2, comma usecase("K28.5 D23.7") work correctly, but comma usecase("K28.5 K23.7") does not work correctly(find K0.0 at receive side).

    Case 2 : Ethernet Tester ->TLK2711 board 1 -> TLK2711 board 2 -> Ethernet Tester

    Case 2-1. When perform uni-directional transfer,  both comma usecase("K28.5 D23.7" and "K28.5 K23.7") work correctly.

    Case 2-2. When perform bi-directional transfer,  comma usecase("K28.5 D23.7") work correctly, but comma usecase("K28.5 K23.7") does not work correctly.

    As a result, some of usecases, when user use comma command "K28.5 K23.7", data error happen.

    It seems that this error causes depending on network load. The question is

    * Is load for TLK2711 different when TLK2711 treat K code and D code ?

    Best Regards,

  • 0 in reply to Ryuuichi machida
    TI__Mastermind 19235 points

    Hi,


    TI verified that the D23.7, and K23.7 are both parity neutral.  So, they both should cause the running disparity to flip insuring that the correct comma is received.  

     
    The reported observation that the size of the transfer would have an impact on TLK2711 performance does not agree with our expectation based on design.

    • Question: Is this observation really consistent based on your results upon multiple iterations?  Is the data valid up until the K code is received?

    TI  would recommend having the comma be more frequent.  
     
    One more performance area to consider is signal integrity.

    • Question: Could you provide an eye diagram of the RX signal? 

    Lastly, it would be good to verify the jitter on both RX and TX clocks. Due note that this TLK2711 device requires pk-pk clock jitter of 40ps or less.

    Cordially,

    Rodrigo Natal

    HSSC Applications Engineer

  • 0 in reply to Rodrigo Natal
    Guru 12620 points

    Hello Rodrigo-san,

    Thank you for your reply.

    >Question: Is this observation really consistent based on your results upon multiple iterations?  Is the data valid up until the K code is received?

     Is this observation really consistent based on your results upon multiple iterations? 

    Ans. Yes, I heard that customer tried several times.

    Is the data valid up until the K code is received?

    Ans. I'm sorry I'm not sure how we could confirm about above. Which portion should we check to make sure about above ?

    >Question: Could you provide an eye diagram of the RX signal? 

    Yes, I could send eye pattern at RX signal and send TXCLK(GTX_CLK) as well.

    However, let me confirm about below before sending data.

    1. In case of TXCLK, which setting should we use as clock edge rising or falling ?(we used rising as edge detection.)

    2. Should we set bandwidth limitation to confirm RX signal and TXCLK ?

        As you said that I understood that 40ps or less should be required for TXCLK. However there is no description about bandwidth.

        I guess that 40ps is required for certain bandwidth (Ex. Highpass f/40, low pass f/20) not all range of bandwidth.

        I believe that you have this requirement for RX signal as well.

    Best Regards,

  • 0 in reply to Ryuuichi machida
    TI__Mastermind 19235 points

    Hi,

    I'm sorry I'm not sure how we could confirm about above. Which portion should we check to make sure about above ?

    • The question here is related to protocol. Have you checked your data with protocol analyzer to make sure format is valid?

    However, let me confirm about below before sending data.

    1. In case of TXCLK, which setting should we use as clock edge rising or falling ?(we used rising as edge detection.)

    2. Should we set bandwidth limitation to confirm RX signal and TXCLK ?

    • I don't think clock edge should matter. Rising is fine
    • I would not expect that bandwidth limitation to be required. Electrical bandwidth for measurement channel needs to be high enough for 2.5G

    Cordially,

    Rodrigo Natal

     

  • 0 in reply to Rodrigo Natal
    Guru 12620 points

    Hello Rodrigo-san,

    >The question here is related to protocol. Have you checked your data with protocol analyzer to make sure format is valid?

    They confirmed data by using chip scope(check inside FPGA).

    they confirmed K0.0 on chip scope.

    Customer said that they do not share their data on public. So I will send email about below.

    * Eye pattern

    * UseCase table which they confirmed

    Best Regards,