• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 2334 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.

66AK2H12 Ethernet problem

UNA
Mastermind 7980 points

Other Parts Discussed in Thread: 66AK2H12

Hello,
 
My customer has problem about the ethernet of 66AK2H12 with their boards.

I will described below for more detail.

 
1: The problem is that the ethernet of 66AK2H12 do not complete the auto-negotiation.
2: This problem is happening some of customer board.
3: They are using 88E1512 ethernet phy.
4: If the 66AK2H12 is wormed, this problem will not occur.
5: This problem is dependent on the 66AK2H12 device, because it was confirmed by replace the device of good board and failure board, So failure was pursed the device.
 
 
I have a question that which one is the block(function) to be affected by the temperature change in the following diagram?
and which is register for changing the setting of the block?
 
Best regards,
H.U
  • 0
    TI__Guru* 81335 points
    Hi H.U,

    I will ask our hardware experts to comment here. Thank you for your patience.
  • 0 in reply to Raja
    TI__Mastermind 46460 points

    H.U.,

    All of these IP blocks can be affected by changes in temperature.  They are also affected by silicon process variation.  Additionally, process, voltage and temperature changes affect the drive impedance of the transmitters and the termination impedance of the receivers.  However, this does not indicate that temperature or silicon variation is the root cause of the problem.  The 66AK2H12 is designed and verified to operate their interfaces robustly across the rated temperature and voltage ranges.  The described problem appears to indicate a marginal PCB layout where changes in silicon or temperature improve or inhibit operation.  Please verify that the SERDES layout rules have been met as defined in the KeyStone II Architecture Serializer/Deserializer (SerDes) User's Guide (SPRUHO3B).

    Tom

  • 0 in reply to Tom Johnson 16214
    Mastermind 7980 points

    Hi, Tom

    Thank you for your reply.


    >All of these IP blocks can be affected by changes in temperature. 

    Which IP block is particularly susceptible to a change in temperature?
    We want to try to change this IP block parameter in order to confirm whether the phenomenon changes.

    >Please verify that the SERDES layout rules have been met as defined in the KeyStone II Architecture Serializer/Deserializer (SerDes) User's Guide (SPRUHO3B).

    Let me confirm with customer and get back to you.

    Best regards,
    H.U

  • 0 in reply to UNA
    TI__Mastermind 46460 points

    H.U.,

    In the other E2E thread, it is reported that there are 12 failures out of 1500 machines.  Do these 12 always fail or only occasionally?  That is the pass/fail ratio?  If they are powered on and report a failure, do they then succeed if the unit is simply rebooted?  Is warm-boot an option?  Of the other 1488 not reported to fail, do they always pass?  Have you tested any of these 'passing' units many times to make sure they always pass?

    You stated that heating the failing devices cause the problem to clear.  Can you provide more details about this test?  Does this work on all failing boards?  How much heat is needed?  What is the chip temp when it fails and when it passes?

    Tom

  • 0 in reply to Tom Johnson 16214
    Mastermind 7980 points
    Hello, Tom


    >Do these 12 always fail or only occasionally?

    Always fail when normal temp.


    >That is the pass/fail ratio?

    Reproducibility of the problem is 100%.


    > If they are powered on and report a failure, do they then succeed if the unit is simply rebooted?

    Yes, if the 66AK2H12 is warmed.


    >Of the other 1488 not reported to fail, do they always pass?

    They tasted in the 10 units that has no problem, but these were always pass.
    Although they were also carried out cold test(0 degrees), behavior in these units were not reproduced


    >Does this work on all failing boards?

    yes, the problem to clear if heating the these devices.


    >What is the chip temp when it fails and when it passes?

    There are individual differences, I will show more detail below.

    26~35 degrees : 1 unit
    36~45 degrees : 6 units
    46~55 degrees : 4 units
    over 70 degrees : 1 unit


    >Please verify that the SERDES layout rules have been met as defined in the KeyStone II Architecture Serializer/Deserializer (SerDes) User's Guide (SPRUHO3B).

    They are designed in accordance with the layout rules of the document.


    We are investigating the value of the Serdes registers now.
    Customer referred "fw_pdk.c" file as follow to set the Serdes registers.

    \pdk_keystone2_3_01_00_03\packages\ti\drv\nwal\test\common\c66\bios\pdkv3\fw_pdk.c

    Even when compared with the latest version of the SDK, I do not see the difference of the registers setting.
    it seems that this files is not updated for serdes register setting

    \pdk_k2hk_4_0_2\packages\ti\drv\nwal\test\common\c66\bios\pdkv3\fw_pdk.c

    Which files sholud we referred? Alternatively, Colud you update the "fw_pdk.c" file?


    Best regards,
    H.U
  • 0 in reply to UNA
    TI__Mastermind 46460 points

    H.U.,

    We need help from the software team.  If all of the layout rules are met, then the next probable issue is SERDES tuning to optimize the SERDES transmitter and receiver settings as appropriate for the customer's board design.  There is a new Application Report "SERDES Link Commissioning on KeyStone I and II Devices" (SPRAC37) available that provides an overview of the tools and techniques available.  Please review with the customer and then provide the TX parameters chosen along with an explanation of how they were chosen.  I have added a SERDES software expert to this thread for assistance.

    Tom

  • 0 in reply to Tom Johnson 16214
    TI__Guru* 95265 points

    H.U.,

    Keystone II SGMII is 4-lane PHY-A, we saw similar link stablility issue on another custom boards. Please check the Lane_02C registers for each of the four lane, make sure bit 21:20 PMA_LN_DFE_BW_SCALE is 0x3, not 0x1.

    Regards, Eric

  • 0 in reply to lding
    Mastermind 7980 points
    Hello, Eric

    Thank you for your reply.
    Serdes UG is not described the details of Lane_02C registers, Please tell me the address information(register map) and the description of this registers.

    Serializer/Deserializer (SerDes) for KeyStone II Devices User Guide
    www.tij.co.jp/.../spruho3b.pdf

    Best regards,
    H.U
  • 0 in reply to UNA
    TI__Guru* 95265 points
    H.U,

    We are updating the Serdes UG and the current posted one doesn't have lane_02c information and thus can't discussed in the forum.

    What I can do, please tell me what is the exact SW release you are using, Linux or RTOS and release version? What interfaces are used? Like SGMII, 10GbE, SRIO?

    I can check the Serdes configuration to make sure the setting are correct.

    Regards, Eric
  • 0 in reply to lding
    Mastermind 7980 points
    Hello, Eric
     
    Customer has set the serdes registers of SGMII the following file to reference.
    We want to update the serdes configuration of this file.
     

    mcsdk_bios_3_01_00_03 (pdk_keystone2_3_01_00_03):
    \pdk_keystone2_3_01_00_03\packages\ti\drv\nwal\test\common\c66\bios\pdkv3\fw_pdk.c

     
    Best Regards
    H.U
  • 0 in reply to UNA
    TI__Guru* 95265 points

    H.U,

    The lane 02c:

       write_32_mask(CSL_NETCP_SERDES_CFG_REGS, 0x22C,0xFF0000FF,0x00100800); ====> this should be 0x00300800

    same should be updated for the other lanes: 0x42c, 0x62c and 0x82c.

    Regards, Eric

  • 0 in reply to lding
    TI__Guru* 95265 points

    H. U.,

    Please check if they update this bit-field from 0x1 to 0x3 can resolve the problem or not? Also, please answer me whether they used other periphals like SRIO, XGE, etc? For all the perhiprals they used, for the lane register 02c, that bit field needs to be programed to 0x3.

    Older CSL release missed this setting, or even the CSL is correct, but the code customer referred to doesn't has this updated can still cause the issue.

    Regards, Eric

  • 0 in reply to lding
    Mastermind 7980 points

    Hello, Eric

    Thank you for your information.
    I will ask the customer for confirmation and get back to you.

    Best Regards,
    H.U

  • 0 in reply to UNA
    Mastermind 7980 points
    Hi, Eric
     
    I received the ATE Verification Report : "TI QTS #: 469296-1 and 469298-1"
    Although we did not find the problem in this test, is it possible for you to test by using the socket EVM with the customer chips?
     
    Best Regards,
    H.U
  • 0 in reply to UNA
    TI__Mastermind 46460 points

    H.U.

    I informed the FAE that we did not expect any problem to be found.  We are not surprised by the results.

    There has been no evidence of SERDES lane tuning in this discussion.  This is a customer responsibility.

    We have informed you of an Applications Note that highlights the tools available for tuning the SERDES configuration.  We have also informed you of new software releases that better control the SERDES.  We will help you walk through these integration tests but we cannot do it for you.

    Tom

  • 0 in reply to Tom Johnson 16214
    Mastermind 7980 points
    Hi, Tom
     
    Thank you for your reply.
    I will feedback the customer situation.
     
    The customer was modified to suit the setting of Serdes registers to the latest version of the SDK.
    As a result, the failure boards began to work correctly.

    I was a slightly confused for a description of the Serdes register, however our customers were convinced by well explained.
    So, this problem has been resolved all.

    Thank you and best regards,
    H.U