• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 101 subscribers
  • Views 349 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM3359: RGMII board design with DP83869 Ethernet PHY & RGMII clock delay

Sagar B N
Prodigy 90 points
Part Number: AM3359
Other Parts Discussed in Thread: DP83869HM,

Tool/software:

Hello All,

We are having RGMII Interface connected between AM3359 and DP83869HM PHY for 1G Copper Ethernet in our board design. Needed help in board layout design for RGMII Interface.

Q1: For RGMII Receive lines, AM3359 processor datasheet mentions that "RGMII[x]_RCLK must be externally delayed relative to the RGMII[x]_RD[3:0] and RGMII[x]_RCTL signals to meet the respective timing requirements". DP8389HM PHY Datasheet mentions that  " By default RGMII shift mode will be activated. Both transmit and receive signals will be delayed by 2ns". As per my understanding, Ethernet PHY will provide the required delay for the RGMII RXD lines without requiring any delay to be added to the RCLK clock trace on PCB. 

Q2: For RGMII Transmit lines, AM3359 processor datasheet mentions that "The EMAC and switch implemented in the AM335x device supports internal delay mode, but timing closure was not performed for this mode of operation. Therefore, the AM335x device does not support internal delay mode." As per my understanding, It looks that we need to delay RGMII[x]_TCLK wrt to that data lines by 1.5ns to 2ns as per the RGMII spec. Does the Ethernet PHY takes care of the delay part without any PCB trace delay ? (DP8389HM PHY Datasheet mentions that  " By default RGMII shift mode will be activated. Both transmit and receive signals will be delayed by 2ns".)

We are doing length matching for RGMII[x]_RD[3:0] and RGMII[x]_RCTL with respect to clock RGMII[x]_RCLK with constraint of 11ps (60mils, Std FR4). Also, same 11ps constraint length matching is followed for RGMII[x]_TD[3:0] and RGMII[x]_TCTL with respect to clock RGMII[x]_TCLK.

Please let me know if there's anything that needs to be taken care in the board layout for delaying RGMII TX/RX Clock. Can we rely on the Ethernet PHY for the required RGMII standard timing delays.

  • 0
    TI__Guru 60815 points

    The original RGMII standard only defined timing where the data and clocks were changing at the same time. This was problematic for many implementations because it wasn't easy to insert enough delay with the PCB, and any external delay element had too much variability across operating conditions. The RMII standard was updated shortly after its introduction to include on option for the clock to be delayed at the transmitter, which would occur in the MAC on the transmit data path and in the PHY on the receive data path. There were a lot of MAC devices already released into production without the option of inserting this delay. Therefore, most of the PHYs were designed to include on option to insert the delay in the transmit data path that was coming from the MAC and the receive data path that was going to the MAC. That is the case for the DP83869HM PHY, and the delay option is enabled for both data paths by default.

    The AM335x has the option to insert this delay in the transmit data path going to the PHY, but as mentioned in the datasheet this mode was not timing closed.

    You should perform a timing analysis of each signal path using the setup/hold requirements of each device along with the output delays of the attached device and your actual PCB delays to confirm each signal has timing margin. If not, you may need to adjust your PCB trace lengths to resolve any timing concerns.

    Regards,
    Paul