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.

AM3358 starter kit; customized hardware interfacing for Gbps Ethernet Interface without Delay mode

Hi,

We are designing Am335x starter kit based customized hardware. we are incorporating our required modifications in the TI provided Am335x starter kit Schematics and PCB design.

we have replaced 1 of the 2 on board phys with an Ethernet switch, but according to Am335x starter kit Errata,

" While the AM335x Starter Kit EVM has 2 Gb Ethernet PHY’s, AR8031A’s, on the
board, the PCB was designed to use internal clock delay mode of the RGMII
interface and the AM335x does not support the internal clock delay mode. Therefore,
if operating the Ethernet in Gb mode, there may be problems with the
performance/function due to this. The AR8031A PHY supports internal delay mode.
This can be enabled by software to guarantee Gb operation. However, this cannot
be done to enable internal delay mode for Ethernet booting."

As we are customizing so i need guideline to re-route or interface ethernet switch with AM335x

  1. is it possible to design PCB without internal clock delay mode of the RGMII interface?
  2. what will be the benefit in terms of performance for  the PCB design without delay and how to design a PCB routing without internal clock delay mode of the RGMII?
  3. on the other hand, if we don't modify  PCB routing for Ethernet interface then what kind of  internal delay mode must be supported by our newly interfaced Ethernet switch  , I mean there is no specifications are mentioned for internal clock delay mode of the RGMII?
  4. Finally, Which above mentioned  option is suitable and what are the related pros and cons to that ?

I am really confused right now and couldn't find any relevant information for this issue, so any kind of help is greatly appreciated !

  • Hi,

    I will ask the Ethernet experts to comment.
  • 1) Yes, but the PHY will need to support RGMII-ID (Internal Delay Mode) on both the TX and RX paths. An additional caveat here is that if you wish to boot via ETH, the PHY must not only support RGMII-ID, but ID must be hardware-configurable (strap-able) because the SoC ROM code will not attempt to set any ID parameters inside the PHY. If you don't need to boot from ETH, then the SoC can configure the relevant ID registers inside the PHY via SW after the OS loads.

    2) RGMII requires that the clock be delayed in relation to data by  ~1.8ns. Previous to the RGMII 2.0 update, the easiest way to accomplish this was to make the CLK trace(s) ~10.8" longer than data to make use of PCB propagation delay.  This was not ideal, so RGMII v2.0 introduced Internal Delay which allowed PHYs to incorporate the delay rather than relying on layout tricks to accomplish same. Your best bet is to review the RGMII v2.0+ specification itself for all the details. Section 3.3 has the particulars. Bottom line here is that if you want to design a PCB that doesn't introduce the required delay(s), the chosen PHY must do so.

    3) Refer to #2 and the spec itself for this.

    4) If you need to boot from ETH, either choose a PHY that can be HW -strapped to enable RGMII-ID on both TX and RX automatically or accomplish the required delay via board layout. If you DON'T need to boot from ETH, you can choose any RGMII PHY that provides RGMII-ID functionality (again, on both TX and RX) via PHY registers. Once the SoC has booted to the OS, SW can program the PHY to enableID prior to needing ETH functionality.

    -DK