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: SGMII to Copper - Procedure to achieve speed match

Part Number: DP83869HM

Hello,

Our product is using a DP83869HM IC. We have configured it through the HW straps to SGMII to Copper Mode 1000/100/10, Auto Negotiation, Auto MDI-X.

Also we control the MDIO pins of the DP83869HM and we can read and write to the registers if needed.

 

An RJ45 connector through magnetics is connected to the PHY of the DP83869HM and the SGMII is connected to an SFP. (This describes our device)

As you can see from the attached block diagram we can successfully connect our Device A with our Device B (Device A is the same product with Device B), when equally speeded devices are connected to the copper sides of our devices. 

But our problem is that when a device 1000/100/10Mbps capable is connected to the copper side of our device A and a device 100/10Mbps capable is connected to the copper side of our device B, they are both connected at different speeds.(1000Mbps and 100Mbps).

As a result there is no communication between those 2 devices (as expected). Although, we continue having the same problem even when we select 100Mbps speed (with Auto Neg disable) at BSCR register only for our device A.

We were expecting that the device A will be forced to 100Mbps speed in order to achieve speed matching on both devices. Although this didn’t work.

 

Is it possible to achieve communication between different speeded devices by downlink the higher speeded device and achieve speed match?  

 

Thank you.

  • Hi Konstantinos,

    Auto-negotiation will only work for the copper side, not the SGMII side, so we would expect you to have to manually select the speeds in this configuration. I have a few question as follows.

    1. Can you please tell us what register settings you used to force the 100Mbps speed on device A?

    2. Assuming device A is a DP83869HM, what part number is device B?

    3. Please tell us how you are determining "this didn't work"

    Thanks,

    David

  • Hi David,

    Thank you for the quick response.

    For the 1 question:

    Initially the auto neg is enabled in register BMCR (value 0x1140). A device which is connected to our device A (copper side) connects at 1000Mbps. After, because the device B copper side has a device connected at 100Mbps, we need to force device A to 100Mbps to ensure speed match. We write to BMCR 0X2100 and to FX_CTRL 0x2100. After these register writes the device which is connected to the copper side of device A, can't connect to our device A.

    For the 2 question:

    Device A is exactly the same product with device B. Which means they  both use DP83869HM.

    For the 3 question:

    We are using an Agilent N2X protocol analyzer. It is connected to the copper side of the devices A and B. It transmits data FD. When we force device A (as explained at q2) to 100Mbps, the N2X can't connect. So no data received. If we disable the auto neg from n2x and force it to 100Mbps then it works again with no problem.

    I think the problem is that N2X initially is in auto neg mode as our devices are. But in order to force to 100Mbps the HM83869HM I have to disable the auto neg (reg. BMCR). 

    Thank you,

    Konstantinos

  • Hi Konstantinos, 

    This is expected behavior. Auto-negotiation only works if it is running on both sides of the link. If it is disabled on the DP83869HM, then the N2X will not be able to determine the correct link speed. 

    So there is no issue here. Continue manually forcing the DP83869HM and N2X to the desired link speed as you have been doing. 

    Thanks,

    David

  • HI David,

    I have attached you a new block diagram which is shown a scenario which doesn't work.

    (We don't know what device is connected to the copper side of Device A and Device B. It is possible that devices with different speeds are connected. The Laptop and Desktop PC are shown in the example are chosen only as an example.)

    In this scenario, the laptop is capable of 1000/100/10Mbps and Device A copper side is connected to 1000Mbps (Auto negotiation).

    The Desktop PC is capable of 100/10Mbps and Device B copper side is connected to 100Mbps (Auto negotiation).

    In this scenario there is no communication between Laptop and Desktop PC. 

    Without changing any setting to the Laptop or Desktop PCs, how can we achieve communication?

    PS: If the Laptop and the Desktop PC were both capable of connected to the same speed (e.g. 1000/100/10Mbps  or 100/10Mbps), the communication will had been successful.

    Thank you,

    Konstantinos

  • Hi Konstantinos, 

    This is not a capability that is possible with your described configuration.

    Auto-negotiation in the PHYs is dominated by the copper side, so a PHY will link up to the fastest speed available to itself and a link partner on the copper side. It is not possible to have an additional PHY on the SGMII side reconfigure it's link speed based on this. This is why you are seeing Link OK between the laptop/desktop and the respective PHYs , but no communication between device A and device B, since there is a mismatch in speeds.  

    The only solution to this issue is to manually set all the speeds to 100Mbps, as you have noticed solves the problem. 

    Thanks,

    David

  • Hi David,

    Thank you for the clarification ( I was expecting it). But I was wondering if there is a way to achieve that by software through mdio. If there is an application note.

    Otherwise, I can't ensure the link if I don't  know  the speed of the connected devices. The link will work only for devices it the same speed capability. Am I right?

  • Hi Konstantinos, 

    There is no way to achieve that by software through mdio. The only solution is to manually set the laptop and device A to 100Mbps. 

    Thanks,

    David 

  • Hi David,

    We achieved it by using the desired advertised speed and triggering the renegotiation.

    Thank you 

    Konstantinos