• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 748 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.

[FAQ] AM62A3: CPSW3G RGMII phy-less interface to external switch

Gunter Schmer
Genius 14212 points
Part Number: AM62A3

Tool/software:

Hi,

a customer is using the AM62A and connects to an external ethernet switch with the RGMII interface. We are looking at the appnote 

https://www.ti.com/lit/an/sprad07/sprad07.pdf

The design currently does not have any delay between clock and data in hardware traces, and would rely on the usage of internal delay on the CPSW or external switch side. This is highlighted in the appnote on page 11

3.3.1 Software and Configuration Issues

These happen when any one or multiple issues occur:

1. Changes in Ethernet Firmware or ENET-LLD have not been done correctly 2. Linux DT changes have not been done correctly 3. SERDES muxing is not done correctly as per recommendation (for SGMII only) 4. RGMII Connection should pay attention to set the recommended RGMII delay through the ENETn_CTRL Register.

What options do we have to set an internal delay in the CPSW3G switch for a phyless RGMII interface?

The document also mentions a patch for the J7200, which also indicated that internal delays may be needed

https://patchwork.kernel.org/project/linux-amlogic/patch/20161125131201.19994-2-martin.blumenstingl@googlemail.com/

Can you let me know if there are any registers in the CPSW that can set such internal delay, or options to work around this to make an RGMII phyless interface work?

Thanks!

--Gunter

  • 0
    TI__Mastermind 27050 points
    Gunter Schmer said:
    1. Changes in Ethernet Firmware or ENET-LLD have not been done correctly 2. Linux DT changes have not been done correctly 3. SERDES muxing is not done correctly as per recommendation (for SGMII only) 4. RGMII Connection should pay attention to set the recommended RGMII delay through the ENETn_CTRL Register.
    Gunter Schmer said:
    Can you let me know if there are any registers in the CPSW that can set such internal delay, or options to work around this to make an RGMII phyless interface work?

    Unfortunately the SW configurable RGMII delay is not a feature available in AM6x devices. Some old versions of the TRM mistakenly carried the register over, but in current revisions it should be marked reserved. See https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1292438/am625-rgmii-internal-transmit-delay-selection .

    So the RMGII HW needs to be designed such that the timing requirements are met, there is no SW managed adjusting of the delays.

  • 0 in reply to Pekka Varis
    TI__Mastermind 40090 points

    Hi,

    As Pekka points out there this is a HW layout problem. Please note that when in RGMII mode there is an automatic 2nS delay added to the TX Clk with respect to TX data by the MAC. When implementing a MAC to MAC or external switch it is required that the TX Clock of the other device is delayed with respect to that data by 2nS. This both senders are implementing the necessary clock delay.

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    TI__Mastermind 40090 points

    Hi Gunter,

    I am closing this thread due to the problem changed to a question about modifying MAC drive strength on this device which is not a possibility.

  • 0 in reply to Schuyler Patton
    TI__Guru**** 190459 points

    Hi All, 

    Refer below results on the MAC to MAC interface testing.

    One thing I would like to add regarding delays is that in RGMII mode the CPSW automatically adds a ~1.2nS delay to the TX clock respective to the TX data. This is a fixed delay. In a MAC to MAC configuration the other device connecting to the AM62a must also insert a 2nS delay on its TX data for the TI device to receive that data.

    They were able to bring up the external NXP ethernet switch connected with MAC to MAC RGMII interface! Thanks for all the internal delay information. The issue was actually more on the ethernet switch configuration side to get it up.

    Regards,

    Sreenivasa