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.

TLK10031: TLK10031 bring up issue

Part Number: TLK10031
Other Parts Discussed in Thread: TLK10232

Hello,

I have followed the steps in this thread:

https://e2e.ti.com/support/interface/f/138/p/640120/2362301#2362301

However, I was not able to pass the pattern generator test. The LN error counters showed 0xFFFD always.

Please help.

  • Fawaz,

    TLK10031 will show 0xFFFD after its initial value after power-up. Once auto negotiation configuration is complete or auto negotiation is disabled, the LS error counters will increment to 0xFFFF based on the data present on the LS side. Do you have auto-negotiation enabled and are you planning on using auto-negotiation? Depending on your application I recommend disabling auto-negotiation and configuring the link manually. Are you using optical modules for this application?
  • Fawaz,

    Could you please post a detailed explanation with your current issues and how you are testing the device? It seems that you are using  loopback to test the device and I would like to make sure the setup and procedure is correct. Please see this document attached for more info on loopback test.

    TLK Loopback Tests.pdf

  • Yes, we are using optical module and disabled auto negotiation. Thanks for the loop back file. We will share more details shortly.

  • Malik,

    Our setup for the TLK10031 is:

    - HS side: connected using SFP+ optical connector to the SFP+ of another PCI card connected to a PC at 10G rate. (HS currently not connected)
    - LS side: connected to 4 channels XAUI for TX and 4 channels for RX at rate of 3.125 Gbps implemented on a Zynq7000 FPGA. A 10GbE MAC IP is also implemented.
    - MDIO signals: connected to the FPGA.
    - Reference clock is connected to an 156.25 MHz oscillator.
    - ST, Mode_SEL and PRBSEN are connected to pin headers and can be set as needed.
    - TESTEN is pulled low.

    What we were able to achieve:

    1. Communicate with the PHY using MDIO to read registers and configure CLKOUT. We were able to receive CLKOUT successfully.

    2. As Fawaz mentioned, we followed the 5 steps in the mentioned post and returned 0xFFFD (and 0xFFFF sometimes). We are also following pages 10 to 13 in the phy bringup procedures document (e2e.ti.com/.../0638.tlk10232_5F00_BringupProcedures_5F00_v2.pdf)

    But we still can't get the loop back test to work.

  • Mohammad,

    Could you give more explanation when you saw you cannot get the loopback test to work? Are you not seeing the data looped back at all, meaning there is no signal on the LS output (assuming you are test Deep Local Loopback)? Are you seeing a saturated LS error counter? When do you see 0xFFFD vs 0xFFFF in the LS error counter? Could you provide your register configuration of the device?

    I recommend that you start with Deep/Shallow Local loop back. In essence you should try to ensure that the LS side of the device is error free before communicating over the HS side of the device.

  • Hi Malik,

    These are the steps we followed for Shallow loopback test (LS side):

    1. Reset device (write a 1 to 0x1E.0000 bit 15 or assert RESET_N pin)

    2. Make sure the reference clock selection (156.25 MHz or 312.5 MHz) is correct – this is done through register 0x1E.001D bit 12 (default is 156.25 MHz).

    3. Select the LS_TEST_PATTERN and enable LS_TP_GEN_EN & LS_TP_VERIFY_EN

    4. Issue a data path reset by writing 1b'1 0x1E.000E bit 3.

    5. Verify LS_LN1_ERROR_COUNTER,  LS_LN2_ERROR_COUNTER,  LS_LN3_ERROR_COUNTER &  LS_LN4_ERROR_COUNTER.

    Observations:

    1. CLKOUT is working. We connected it to a counter on the FPGA which drives an LED. The LED is blinking.

    2. MDIO read/write operations are working. We sucessfully read default registers values + modified values.

    3. In the shallow loopback test, LS_LN error counters readings for all patterns shown in the following image: (0xFFFF is before running the test and 0xFFFD is after test is done)

    4. When we disable the shallow loop back test, LS_LN counters give 0xFFFF for all test patterns.

  • Mohammad,

    Could you try writing a 1 to 0x1E.000B bit 0 in between steps 3 and 4? This will put the device into shallow loopback mode. Are you using a PRBS test pattern? Is auto negotiation and link training disabled? Is CLKOUT at the correct frequency when measured? Could you share your device register configurations for this test?

  • Hi Malik,

    1. We enabled the shallow loopback mode in betweeen 3 and 4 and got observation #3 mentioned above. Also tried disabling the shallow loopback and got observation #4.

    2. Yes, we used the PRBS test pattern. We tried other patterns and got same results.

    3. No, auto negotiation and link training are left enabled. We tried to disable them and the result is shown in point #5 below.

    4. For CLKOUT, will confirm the measurement and get back to you.

    5. Our device register configuration are as follows:

    1- Reset Device
    Write 0x8000 to 0x1E.0000

    2- Set CLKOUT
    Write 0x2F44 to 0x1E.000D

    3- Check LN counters before test
    Read 0x1E.0011
    Read 0x1E.0012
    Read 0x1E.0013
    Read 0x1E.0014

    4- Disable Auto Negotiation
    Write 0x2000 to 0x07.0000

    5-Training Control
    Write 0x0 to 0x01.0096

    6- LOOPBACK_TP_CONTROL
    Write 0x08E7

    7- Issue Path Reset
    Write 0x8 to 0x1E.000E

    8- Read Lane counters
    Read 0x1E.0011
    Read 0x1E.0012
    Read 0x1E.0013
    Read 0x1E.0014

  • Hi Malik, any updates on this?

  • Any suggestions to resolve this?

    I've called TI support several days ago (Ticket: 1-4643474693) and still didn't get help.

    Please advise.

  • Mohammad,

    My apologies for the delayed response. I am unsure what is directly causing your issue via the picture above. Upon reset 0xfffd is first seen in the LS Error counters meaning that no data is following and no decode errors have been seen by the channel to begin to increment the error counter.

    Could you check CHANNEL_STATUS_1, for Channel A and/or B, after your start-up procedure but before you setup for loopback to give me a better idea of the state of TLK10031. if you could you share your entire device register configurations in detail, that would help speed up the process.
  • Hi Malik, thanks for your follow-up.

    Will share the entire device register configuration shortly.

    I just would like to clarify that we aren't sending any data to the Phy on the HS (10G) or LS (xaui) yet, both sides are left floating. We just wanted to confirm basic phy operation by running an on-chip test pattern and verifying it by reading the error counters. Are we following the correct procedures to acheive this?

    Looking forward to your help. We will provide all the needed info asap since our project is reaching a critical state. Your fast follow-up is highly appreciated.

    Regards,

  • For CHANNEL_STATUS_1, please review the image shared in the above post:
    e2e.ti.com/.../2818325

    We are using TLK10031 which is the single channel version.

  • Also for the register configurations, you need it for every register in the phy? Or only the ones used for this test? Can you please list which registers you request?

    We shared the related registers configuration in a previous post:

    https://e2e.ti.com/support/interface/f/138/p/760354/2818325#2818325

  • Mohammad,

    This is not a valid condition to test the TLK10232. There needs to be some connection on either the high speed or low speed side. Even if the internal test pattern generator is running. Accumulated errors will still be seen on in the error registers. You can confirm MDIO communication is functional (already confirmed) and you can also check HS_PLL_LOCK and LS_PLL_LOCK and ensure that the internal PLL's have locked. 

  • Mohammad,

    Could you help me understand what you are trying to validate in your system. We may be able to come up with a procedure that will validate what you are looking for.
  • Hi Malik,

    Here is a simple block diagram of our basic connections between the TLK10031 and Zynq-7035 FPGA. The HS and LS sides of the TLK10031 are currently floating. 10G MAC and XAUI IPs are implemented on the FPGA.

    - As discussed before, we were able to communicate with the PHY using MDIO to read/write registers and configure CLKOUT. We were able to receive CLKOUT successfully.

    - You mentioned that leaving the HS and LS sides floating is not a valid configuration so we are currently configuring a 10GbE PCI card to send data on the HS of the TLK10031 through SFP+ optical connection.

    The questions are:

    1. Can you send us clear phy configuration procedures to bring it up and eventually getting it to read/write from/to the PCI card? We prefer to make loop back tests at LS and HS if possible, so please guide us through this and we will try it and let you know the results.

    2. We have linux running on the FPGA, do you provide any linux and uboot support for the TLK10031?

    Much appreciated.

  • Hi Mohammad,

    1. Can you send us clear phy configuration procedures to bring it up and eventually getting it to read/write from/to the PCI card? We prefer to make loop back tests at LS and HS if possible, so please guide us through this and we will try it and let you know the results.

    • For XAUI-to-SFI/XFI operation, you will need to configure the device for 10GBASE-KR mode and disable the features specific to backplane Ethernet like Clause 73 auto-negotiation and 10G link training. To do this, follow this procedure:

    1. Reset device (write a 1 to 0x1E.0000 bit 15 or assert RESET_N pin)
    2. Make sure the reference clock selection (156.25 MHz or 312.5 MHz) is correct
      • This is done through register 0x1E.001D bit 12 (default is 156.25 MHz).
    3. Disable auto-negotiation by writing 1’b0 to 0x07.0000 bit 12
    4. Disable link training by writing 16’h0000 to 0x01.0096
    5. Now set SHALLOW_LOCAL_LPBK or DEEP_REMOTE_LPBK to achieve the desired loopback mode.
    6. Write 16’h03FF to 0x1E.8020.  This allows the link settings that would normally be configured through KR training to be configured manually instead.
    7. Depending on the link conditions, you may need to change the default configuration of 0x1E.0003 and 0x1E.0004.  For optical connections, we typically recommend changing HS_ENTRACK (0x1E.0004 bit 15) to 1’b1 and HS_EQPRE (0x1E.0004 bits 14:12) to 3’b101.  
      This can be a starting point, but you may need to do some BER testing to optimize the values.
    8. Issue a data path reset by writing 1’b1 to 0x1E.000E bit 3. (Required once the desired functional mode is configured, at this point the device should be properly configured).
    9. As a sanity check, Make sure LS_PLL_LOCK and HS_PLL_LOCK are read as 1'b1.

    • Please let me know if this is not clear to you. Step 6 should be focused on when you configure the system in it nominal configuration and not in loopback mode. This is so you tune the settings to the appropriate channel characteristics for your application. 

    2. We have linux running on the FPGA, do you provide any linux and uboot support for the TLK10031?

    • We do not provide linux and uboot support for TLK10031.

  • Hi Mohammad,

    Is there any more support needed for this issue? If so please reply with any relevant details so that I can further assist you. For now I will be marking this thread as "TI Thinks Resolved". If you have resolved your issue, please post the solution to the original problem/post for others with similar issues.
  • Hi Malik,

    We are still working on the issue and setting up the 10G source to be able to apply the procedures you suggested.

    This is NOT resolved yet, please bear with us and we will keep you posted.

    Regards,

    Mohammad

  • Hi Mohammad,

    I understand, please let me know if you have any questions.
  • Hi Malik, my apologies for the delayed feedback. We were having our setup ready to apply your suggested procedures.

    We connected a PCIe 10G card (Intel X520) to our Linux PC and ensured it’s successfully detected. Then we connected it to our custom board using SFP+ optical connection as shown below. The LS side is left floating:

    We followed the 9 steps mentioned above and the counters are still giving errors, here is the result:

    Notes:

    1. We didn’t send any data from the PCIe card to our board. We couldn’t send because our custom board doesn’t have an IP yet. Do we need to send data to get this loopback test to work?

    2. We tried the 4 loopback modes and got the same result.

    3. As shown in line #15 (CH status after datapath reset) in the above image, it seems LS_PLL_LOCK = 1 and HS_PLL_LOCK = 0. We don’t know why the HS PLL didn’t lock. Please advise on debugging procedures.

    4. CLKOUT seems to be stopped working. We have an LED indicator that is now always off after connecting the HS side. Before connecting the PCIe to HS side, CLKOUT was working and the LED was blinking.

  • Hello,

    It may be possible that the errors are due to signal integrity issues. You may want to check the links.

    Regards,
    Yaser
  • Hi Yasser,

    Our design strictly followed the same hardware design guidelines used in your TLK10232 evaluation module mentioned in pages 4 and 5 of the SLLU180 document and TLK10031 datasheet. This includes the following:

    1. Using Rogers 4350B dielectric material on the outer layers used to route all multi gigabit (10G and XAUI) signals in a microstrip configuration.

    2. Using 8-Layer stack-up with 2 unsplit reference ground planes at layers 2 and 7.

    3. The use of 0.1uF AC coupling capacitors required by 10G, XAUI and other signals. The package of these caps is 0201 to minimize impedance discontinuities.

    4. Differential pairs of 10G and XAUI signals are all matched to 100-Ohm differential impedance.

    5. Length matching of all 10G and XAUI signals.

    6. Plane cutouts underneath the SFP+ connector 10G pads.

    7. The 156.25 MHz reference clock used has a maximum of 200fs jitter. Its part number is: LMK61A2-156M25SIAT

    Please let us know if we missed any of the design considerations so we can review the design further.

    However, for the loopback testing, we still have some pending points mentioned in our last reply that needs your advice:

    1. We didn’t send any data from the PCIe card to our board. We couldn’t send because our custom board doesn’t have an IP yet. Do we need to send data to get this loopback test to work?

    2. As shown in line #15 (CH status after datapath reset) in the above image, it seems LS_PLL_LOCK = 1 and HS_PLL_LOCK = 0. We don’t know why the HS PLL didn’t lock. Please advise on debugging procedures.

    3. CLKOUT seems to be stopped working. We have an LED indicator that is now always off after connecting the HS side. Before connecting the PCIe to HS side, CLKOUT was working and the LED was blinking.

    Looking forward to your feedback.

  • Hello Mohammad,

    Unfortunately, we are not sure why you are observing these issues, and we are not able to provide any additional help.

    Regards,
    Yaser