• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 166 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.

DP83867IS: DP83867IS: DP83867ISRGZ issue

Ken Li
Prodigy 10 points
Part Number: DP83867IS


Tool/software:

Our Ethernet connection block diagram is as follows. We connect the SGMII communication of the PHY on both sides through the connector.

However, occasionally, when disconnecting the connector and then connecting it again, the computers on both sides fail to establish Ethernet communication.

The DP83867 chip must be reset or the Ethernet cable between the PC and Phy must be re-plugged to restore communication. However, such a method requires at least 2~3 seconds to restore communication, and we want to be able to restore the link quickly.

We speculate that there may have been an anomaly in the clock synchronization when the SGMII interrupt was reconnected. 

Can we read the connection status of the SGMII through the registers of the DP83867? Or can we manually control the PHY chip to do a link training without resetting the PHY chip? This may shorten the reconnection time.

  • 0
    TI__Guru**** 180041 points

    Hi,

    Any chance you can share your schematic?

    You could do a register dump mentioned below

    These registers will enable us to know the status of SGMII link between the PHYs and if auto-negotiation is enabled for SGMII, which is an independent auto-negotiation process from the MDI link. 

    If the auto-negotiation is on, I would suggest to disable auto-negotiation by toggling 0x0014[7] to 0 and put SGMII into forced mode since this link is between two PHYs, not between a PHY and a MAC. Forced mode will make SGMII to follow the MDI speed and configuration so as long as the MDI configuration on either PHY is the same the SGMII should be able to link. 

    Thanks

    David

  • 0 in reply to David (ASIC) Liu
    Prodigy 10 points

    My schematic diagram is not very convenient to share on the forum, but we have only made some simple configurations on the hardware. Most of the time SGMII communication is normal, and the problem of not connecting is only occasional.

    I configured the MDI link to do forced 100 megabit full duplex via the MCU and turned off auto-negotiation. Do you mean that the SGMII interface also does auto-negotiation? Does SGMII occasionally fail to connect with this automatic negotiation? If SGMII automatic negotiation is turned off, can this problem be solved?

    Our SGMII mode uses a 4-wire connection. Can we grab the CLK signal?

  • 0 in reply to Ken Li
    TI__Guru**** 180041 points

    Hi,

    Would you please accept my friendship request so you can send me the schematic in a private mssage?

    The Ethernet and SGMII both have an auto-negotiation process that are independent of each other. Ethernet autonegotiation occurs between an Ethernet PHY and the PHY link partner over the MDI lines. During this process, the two devices exchange information about speed, duplex mode, and flow control and link up at the maximum capability advertised by both link partners. SGMII auto-negotiation is a process where the PHY sends updated control information to the MAC. This control information is specified in the Cisco SGMII Standard. When the MAC receives this information, the MAC acknowledges reception of the updated control information by asserting an acknowledge bit. In TI Ethernet PHY, this acknowledge bit is associated with the register bit SGMII Page Received. In SGMII auto-negotiation, there is no maximization of capabilities, just information exchange between PHY and MAC. So you can choose to disable auto-negotiation either on the MDI or the MAC interface and see which one resolves the link down issue.

    For the 4-wire connection, you can probe directly the MAC interface to measure the signal data rate. 

    Can you also dump out the registers in my previous response? This will help pinpointing the root cause of the issue.

    Thanks

    David