• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 33 subscribers
  • Views 160 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.

DP83867CS: RGMII communication issue - data corruption in the TX path

Navadeep U
Prodigy 45 points
Part Number: DP83867CS


I have made a design using Tri mode ethernet MAC IP (TEMAC) with RGMII interface. The problem I am facing is that the data/ethernet packet being sent from the FPGA logic looks fine on Vivado ILA, but that same ethernet packet shows wrong data on wire shark tool while analzing. Upon closer look of the wireshark data, it seemed that only the LSB data is getting corrupted the MSB bits look just fine. The ethernet IP process the data to be transmitted in the 8-bit which is suitable for GMII and then that data is converted to RGMII. PHY being used is DP83867CSRGZR.

The strap configurations are made to distinguish PHY addresses (3 PHY ICs used in the design) and clock skew related configuration is set to default 2.0ns.

Any hints for debug points and as to what could be happening here?

 

PHY_net_lengths.csv 

phy_mac_rgmii_schematic.pdf 

(attached the RGMII net length report and schematic snaps here for your reference)

  • 0
    TI__Mastermind 21596 points

    Hi Navadeep, 

    Could you try putting the PHY in internal loopback mode and send test packets to see if the error is occurring on the MDI or MII side?


    I suggest to try MII loopback to see if the MII path is okay. And then please try digital loopback to ensure that the internal PHY works. 
    This test will isolate at which point the packet error may be happening. 

    Please let me know. 

    Best,
    J

  • 0 in reply to J
    Prodigy 45 points

    Hi J, thanks for the quick response. We tried to establish a MII loopback but couldn't do it reliably through the TEMAC IP we had on the FPGA side.

    However, interestingly after adding a 500ps delay in the RGMII TX clock, the link started worked with no error packets. This was done through the IDELAY/ODELAY adjustments on the IP side. We have come from using GMII, SGMII in our earlier systems where the timing wouldn't have been as critical as RGMII.