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.

DP83867IS: What causes "XGMII_ERR_INT" to be 1?

Part Number: DP83867IS

Hello.

I connect Xilinx's Zynq-7000 and DP83867IS (CS) and are doing RGMII communication.
There is a problem that Ping packets exceeding 100 Bytes can not be sent.

・ Zynq-7000
It uses PL general-purpose I / O (LVCMOS 25), and the internal module uses "GMII to RGMII" built in by default.

・ DP83867 IS
The I / O voltage is 2.5 V, and all the strap settings are "MODE 1".
* "RX_CTRL" should be set to MODE 3, but changing it did not solve the problem.

I have found a few things that may be the cause of this problem.
・ Near-end noise and far-end noise (overshoot, undershoot) were found on the rising edge or falling edge of the RGMII clock signal and data signal.
・ Impedance matching is not implemented on the RGMII path. (Equal-length wiring is implemented, but the wiring length is slightly longer (120 mm))
・ There are two vias between Zynq-7000 and DP83867IS for RGMII routes. (The eighth layer of the eight layer substrate → the second layer → the first layer)
・ The layer immediately under the wiring of RGMII is the power supply layer.

From the above, I speculated that the cause of the Ping communication failure mentioned above is "RGMII is unstable".

Also, we found that bit 2 (XGMII_ERR_INT) of register 0x0013 is "1".
* Even if 0x0013 is read, it will not be cleared.

I recognize that "This bit is 1" = "RGMII communication failure", but is not it wrong?

Could you tell me what is the cause of this bit becoming "1"?

Thank you.

  • Hi,

    Have you tried to implement internal delay in the TX and RX path through register access?
    Have you tried to operate it at 10Mbps and 100Mbps to see if it improves? Those speeds have less stringent setup/hold times and can help prove your theory.

    That error is triggered when there is a code group error after decoding the MDI.
    Have you read register 0x15 to see if errors are incrementing?
  • Hello.
    Thank you very much for replying.

    > Have you tried to implement internal delay in the TX and RX path through register access?

    I tried all patterns of internal delay of TX and RX (register value: 0000, 0001, ..., 00FF) by accessing 0x0086, but I will not solve it.

    > Have you tried to operate it at 10Mbps and 100Mbps to see if it improves? Those speeds have less stringent setup/hold times and can help prove your theory.

    Also, I am forcing the link speed to 10 Mbps (Full Duplex) by link partner setting now.

    > That error is triggered when there is a code group error after decoding the MDI. 

    What is "code group error" specifically?
    Does this bit have any adverse effect on Ethernet communication?

    > Have you read register 0x15 to see if errors are incrementing?

    0x0015 was always "0" even when the Ping packet was sent normally or when packet loss occurred.
    Although it was possible to check the value in rare cases, it was returned to "0" again as soon as it was read again.
    Looking at the data sheet, it says "It is cleared by dummy write to this register."
    Is this just a failure to read the register?
    (I am accessing registers with MSP-EXP430-G2.)

  • Hi,

    Code-groups are what the PHY turns the raw data on the xMII into before it gets transmitted out onto the MDI.
    It is just an encoding assignment. If the codes get corrupted then there is a flag.
    Can you provide me a register dump please? Also, have you tried to enable shallow loopbacks in the PHY to to see if the errors are on the MDI or RGMII?
    You can use xMII loopback, digital loopback and analog loopbacks but enabling through register access.