DP83869HM: SGMII Back-to-Back PHY Configuration Issue

Hi Jean,

1. The block diagram looks feasible using SGMII-RGMII bridge mode on the DP83869s, though you shouldn't disconnect the SGMII receiving lines. Both SGMII and RGMII are bidirectional interfaces. Forcing these to be unidirectional will likely violate their specs

2. No, You should connect both the transmitting and receiving lines to the PHY for proper data transfer.

3. I've seen that thread as well, however a more recent thread states that auto negotiation does not need to be disabled. You shouldn't have to disable auto negotiation to get SGMII back to back working.

4. To get MII loopback working, you should set register 0x0000 [14] to '1'. Does this register write not loopback data on the MII lines in your system?

Jean said:

The RX clock signals for the PHYs have a frequency of 2.5 MHz, which I'm assuming means no link has been established or there is some other issue going on.

This is strange. The RX_CLK should output a 125MHz clock from the PHY when in RGMII mode. Can you share the schematic for this design? I can take a look for implementation issues.

Additionally, can you elaborate on why you're trying to force a unidirectional SGMII connection? I'm not aware of this being done before with any of our PHYs.

Best,

Shane

Hi Shane,

Unfortunately, I cannot share schematics for this design. 

We were able to verify that the PHYs are configured to SGMII-RGMII bridge mode. The board was modified such that the SGMII lines for each of the PHYs are connected to another board with an SFP port via jumper wires. We used packeth and wireshark on a linux machine to send/monitor network traffic going in and out of the port. I think this test confirmed that the strapping configuration for the PHYs is correct and that there are no timing issues with the RGMII interface.

I have a few more questions listed below.

1. How is a link established when the PHYs are setup to work in bridge mode? 

2. Is it possible to force a link via the registers?

Thanks,

Jean

Hi Jean,

In RGMII-SGMII mode the RGMII interface will adjust to the SGMII interface speed. The SGMII interface speed will be determined through SGMII auto negotiation. In this mode the RX_CLK will default to 2.5MHz if there is no link on the SGMII side. I believe this is what you were seeing previously:

In SGMII-RGMII mode the roles get reversed. The SGMII interface adjusts to meet the RGMII interface speed, so the RGMII link needs to establish first.

Jean said:

Is it possible to force a link via the registers?

By force a link, do you mean disabling the SGMII auto negotiation? This is possible with the SGMII_AUTONEG_EN register:

Best,

Shane

In the troubleshooting guide for the DP83867, section 3.5 mentions how to resolve link establishment issues between two PHYs operating at 1G speed. Are these solutions applicable to the DP83869 part as well? I was thinking of configuring one PHY as a master and the other as a slave and then doing a soft reset via the MDIO registers. Currently the activity LED blinks for both PHYs on our prototype board, but it there is no link establishment.

Hi Jean,

Yes these solutions are applicable to DP83869, though they are intended to help with MDI-side link up issues. Since you're using SGMII-RGMII bridge mode the link happens over SGMII, not the MDI (copper) lines. How are you checking the link status on the DP83869 (LED_0/Register/...)?

Can you check that the SGMII routing is correct?

Best,

Shane

Hi Shane,

I will try checking the link status via the registers. I think the SGMII routing is correct because we are getting an activity light on both PHYs. The SGMII signal routing length on the PCB is about 6 inches. I will read the register that indicates link status (01h) and post whatever I read back. Are there any registers that I should check that would help with troubleshooting this issue?

Hi Jean,

For my own understanding, is the issue that the SGMII link is not establishing? I'm wondering what symptom you're seeing with the DP83869 that is showing an issue (ping not working/packet errors/ no link/...)

If the SGMII link is the problem, it would be good to see register 0x0037 [0] to check whether the SGMII auto negotiation completes.

Additionally, the link status is not shown in 01h when in an MII bridge mode. To see the correct link status, check register 0x0C01 [2]:

If you suspect the SGMII is the problem we have a document with tips for debugging the SGMII interface.

Best,

Shane

Hi Shane, do you know if it's even possible to get two of these PHYs connected back through SGMII with both of them strapped for SGMII-RGMII mode?

The setup is as follows:

- FPGA A's EMAC connected to PHY A through RGMII

- PHY A connected to PHY B through SGMII

- PHY B connected to FPGA B's EMAC through RGMII

- Both PHYs are strapped for SGMII-RGMII mode.

Would such a setup work with these PHYs?

Thanks,

Phillipe

Hi Phillipie,

Yes this configuration is valid.

I'm not clear what the issue is that you're seeing. The only symptom I've seen is that the RX_CLK signal is 2.5MHz, which would be expected in RGMII-SGMII mode.

Best,

Shane

Ok. Thank you for confirming that our setup is valid.

I will provide more context.

- RGMII-SGMII mode: We confirmed the strapping on both of them by reading the register 0x1DF.

- We turned off autonegotiation by writing to register 0xC00. Some progress was made as we noticed the link LED turning on and the activity LED blinking whenever we attempt to send traffic through. We also measured the RX_CLK to be 125MHz.

However we are not able to receive data on both ends at our EMAC within the FPGA.

Earlier, we were able to confirm that the RGMII interface between the FPGA's EMAC and the PHY was correct by temporarily tying the SGMII interface to an SFP cage on a separate board with the help of our tech. We were able send and receive traffic to the SFP module in the cage.

Is there a step that we are missing to get the two PHYs to communicate appropriately?

Are the link and activity leds turning on for both connected PHYs or only one PHY?

It sounds like the RGMII->SGMII connection works, so the next step would be to check the SGMII->SGMII connection. If both PHYs are showing link up then this ought to be valid. To confirm this, I suggest reading the STTS_LINK_STATUS register in both PHYs as well.

Best,

Shane

We indeed read the status register 0xC01 and it reported that link was up for both PHYs.

The link LEDs were solid on.

The activity LEDs were blinking when we attempt to send traffic through.

There's no other steps you think we might have missed?

The SGMII link looks ok, and the activity LEDs show data is passing through. Are you attempting to ping from one MAC to the other or are you generating packets on one end and checking them on the other?

Is the receiving MAC showing packet loss or no packets at all?

Best,

Shane

Yes I am sending packets from one MAC and check them on the other MAC, but we are not receiving

any packets on the other side at all.

After SGMII link is up (LEDs solid on) are both PHY's RX_CLK outputs still 2.5MHz?

2.5MHz is expected while there is no link on SGMII, however the speed should increase after the SGMII link is up

Best,

Shane

Hi Shane,

I have a separate question relating mirror mode. If I have a PHY configured to SGMII-to-Copper mode, does enabling mirror mode only affect the MDI signal polarity or does it also affect the SGMII signals too? Basically, if I have this mode enabled, do I need to swap the polarity for the TX or RX SGMII lines going to the PHY?

Thanks,

Jean