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.

DP83869HM: RGMII-SGMII Bridge mode Autonegotiation not working

Part Number: DP83869HM

We are using a DP83869HM to bridge between RGMII and SGMII. 

The RGMII side of the DP83869HM is connected to a Xilinx Zynq-7000 integrated MAC. The SGMII side is passing through a backplane to a board containing a VSC8564 (which is converting the SGMII to 1000BASE-T).

Two instances of this arrangement are implemented (see below) but a single one is currently being debugged (the other is greyed out below but its relevance is given later).

The VSC8564 is initialised first followed by the DP83869HM. The DP83869HM is configured into the desired mode with the strap configuration.

The register access sequence to the DP83869HM is shown below. The lines beginning BMCR are a print out of the most relevant registers.

Register accesses are described with some text and then what the access is, for example PHY_TI_CFG4 (ermw[0x0031] &= 0xFF7F) is an extended read-modify-write access to register 0x31, ANDing the value with 0xFF7F as the modification of the value read.

BMCR[0x0000]=0x0140 BMSR[0x0001]=0x794D SGMIIAnegStatus[0x0037]=0x0003 OPMODEdecode[0x01DF]=0x0043 FibreControl[0x0C00]=0x1140 FibreStatus[0x0C01]=0x617D
sw restart (rmw[0x001F] |= 0x4000)
MII reset (rmw[0x0000] |= 0x8000)
Delay
set PHY_CTRL (w[0x0010] 0x5048)
set RGMIIDCTL (ew[0x0086] 0x0077)
set RGMIICTL (ew[0x0032] 0x00D0)
SW workaround for unstable link when RX_CTRL is not STRAP MODE 3 or 4
PHY_TI_CFG4 (ermw[0x0031] &= 0xFF7F)
Aneg Adv (rmw[0x0031] |= 0x0DE0)
Aneg Adv (rmw[0x0009] |= 0x0300)
Aneg trigger (rmw[0x0000] |= 0x1200)
Waiting for PHY to complete autonegotiation.
BMCR[0x0000]=0x1140 BMSR[0x0001]=0x794D SGMIIAnegStatus[0x0037]=0x0003 OPMODEdecode[0x01DF]=0x0043 FibreControl[0x0C00]=0x1140 FibreStatus[0x0C01]=0x6179
BMCR[0x0000]=0x1140 BMSR[0x0001]=0x794D SGMIIAnegStatus[0x0037]=0x0001 OPMODEdecode[0x01DF]=0x0043 FibreControl[0x0C00]=0x1140 FibreStatus[0x0C01]=0x617D

The final two register state print-outs are one second apart and the last register states are repeatedly read the same for 30 further seconds with no change.

It can be seen that the link status is reported as Link up (BMSR bit 2) and Autonegotiation process is reported as not complete (BMSR bit 5) but no remote fault is indicated (BMSR bit 4).

However, the Fibre Status register also reports Link up (FibreStatus bit 2), but Autonegotiation process is reported as complete (FibreStatus bit 5) but with a remote fault indicated (FibreStatus bit 4).

It's not clear which one is relevant to RGMII-SGMII bridge mode but both indicate a problem. I'd appreciate some help in sorting out this issue.

Background: The backplane/VSC8564/PC parts of the circuit have been tested with an SGMII loopback plugged into the backplane (as shown below). The SGMII links successfully autonegotiate to 1G and the two PC's can ping each other. Therefore, it is assumed that the SGMII links are OK in terms of PCB trace impedances/etc and also the VSC8564 setup is correct.

  • Sorry, the second image is incorrect, the purple boxed device should read VSC8564

  • Hi Graham,

    Remote Fault bit is only relevant for Fiber modes and not RGMII-SGMII bridge mode.

    Are you seeing some issues with the data transfer?

    --
    Regards,
    Gokul.

  • Hi Gokul

    Thank you for responding. 

    The Remote Fault that you state is not relevant to RGMII-SGMII bridge mode - does that apply to the flag in both registers (BMSR and Fiber Status)?

    The link autonegotiation is being reported as not complete in the BMSR so I believe that the link is not fully up.

    If I ignore the flag and try to send messages through the interface chip, pinging between PC and Zynq-7000 ARM processor, there is no communication happening.

    I do not have a great deal of experience with this type of ethernet infrastructure hence my request for help. I have outlined the register accesses I have implemented for initialisation of the DP83869HM chip (and it has the appropriate strap configuration for the mode I require) but I don't know if I'm doing something wrong in the initialisation or perhaps the sequence of events between the DP83869HM chip and the VSC8564 chip in the initialisation/autonegotiation process.

    Regards

    Graham

  • Hi Graham,

    You can ignore remote fault bit in 0x0001 too. You can ignore autoneg complete in 0x0001.

    The status registers read shows the device is all linked up.

    Can you please check if the timing of the interaction between Zync-7000 and DP83869HM is met. You can take a look at align and shift modes of RGMII as outline in https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1096129/rgmii-timing---align-and-shift-mode

    --
    Regards,
    Gokul.

  • Hi Gokul

    I was correctly setting the RGMII timing. 

    It was the status flags that were fooling me......if I use the Link Up bit of the BMSR (bit 2) as an indicator of the SGMII link being OK and ignore the AutoNeg Complete flag (BMSR bit 5), and also ignore the declared speed (which I was reading as 10Mbps from PHY_STATUS reg 0x11 bits 15&14), then the link works and I can communicate across it between ARM processor and PC at 1Gbps.

    Is it sufficient for me to check the Link up bit of the BMSR in order to declare the link as good and working or are there any other bits I should be checking?

    Thanks

    Graham

  • Hi Graham,

    Link up and Autoneg complete bits in 0x0C01 should be sufficient to be declared as good.

    Can you please check with Microchip to see if they can find something from their PHY?

    --
    Regards,
    Gokul.

  • Hi Graham,

    Incase, we don't get any info from Microchip, we can still try some loopbacks to understand the point of failure in our system.

    Please let me know if you think we can run some loopback tests.

    --
    Regards,
    Gokul.

  • Hi Gokul

    Apologies for the slow response but I've had an extended break over Christmas and another matter needed my attention on my return to work.

    The communication between the VSC8564 and the TI DP83869HM chip (via SGMII) is working....having clarified the relevant status bits for the RGMII-SGMII bridge mode with you, the apparent failure to autonegotiate and link between the chips was due to our software inadvertently checking the incorrect status bits.

    Thank you for your help

    Graham