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: Problem with data rate / transfer quality

Part Number: DP83867IS

We are using the DP83867IS component on an adapter board between SGMII and physical ethernet (RJ45-> cable). The following confguration we are using:

  • SGMII as 4 wire interface
  • physical interface: 10/100 BaseT
  • Strapping: RX_D0: mode 1, RX_D2: mode 1, RX_CTRL: mode 3, GPIO_0: mode 1, GPIO_1: mode 1, LED_2: mode 1, LED_1: mode 1, LED_0: mode 2

With that configuration we get the following problem (client = physical interface, server = SGMII):

  • datatransfer from server to client (from SGMII to physical interface) works fine; we are getting transfer rates of appr. 77MB/s
  • data transfer from client to server (from physical interface to SGMII) works wrong; we are getting transfer rates of appr. 200kB/s

Have you got any idea, what we could do to fix that problem?

  • Hi Heico,

    It seems like you may have a duplex mismatch between your server and the link partner connected across the RJ45. How are you setting the DP83867IS into 10/100 base modes?

    Best Regards,
  • Hello Rob,

    Thanks for the quick answer. We don't setting the DP83867IS explizit in 10/100 mode. We are using only the strapping pins and the autoneg. configuration. Could that be the problem? Should we use fix data rate? Is that possible via strapping pins? If I'll disable autoneg. and enable SGMII, which speed will used from the DP83867IS device?

    Best regards,

    Heico

  • Heico,

    What link partner are you using? Can you give me a schematic? Can you also dump registers 0x0 to 0x1f from the DP83867? This will tell me what speed and duplex you are resolving to.

    The ideal way to handle setting the device into 10/100 mode is by setting register 0x9 = 0x0000 and restarting auto-negotiation by setting register 0x0 = 0x1200 or disconnecting/reconnecting the cable.

    There is no way to fix the speed of the DP83867 using straps.

    Best Regards,
  • Hi Rob,

    sorry, on the SGMII side we are using a third party device and we haven't got a circuit diagram of it. We have only a web base managment interface for status etc information of the interface between our SGMII to Ethernet converter and the third party device. For the converter we have used the applcation notes and reference designs from TI for the circuit diagram and the layout tips in the datasheet. So a memory dump is not so easy. Is there any other hints or tips from your side, we could try on our HW? It would be very helpful for us.

    Best regards,

    Heico

  • Hi Heico,

    OK. For hints, if you have throughput problems, usually there is a duplex mismatch. By IEEE default, if the link partner is in fixed speed mode, the connected partner must assume a half duplex connection. If you cannot check DP83867 registers easily, then you should investigate if the connected link partner is in a fixed speed mode.

    If you are performing auto-negotiation, check the DP83867 register address 0x5 which displays the capabilities of the link partner that were detected by auto-negotiation process.

    In addition, SGMII has an auto-negotiation process as well. If your third party device SGMII part enables or disables auto-negotiation, this should be known.

    Third, SGMII auto-negotiation has 2 roles in it: MAC and PHY. The roles are such that the PHY initiates the auto-negotiation process and the MAC responds with a single bit to acknowledge the auto-negotiation. The DP83867 operates SGMII auto-negotiation in PHY mode. If your third party device operates in PHY mode as well, there could be an issue.

    These are the main points I can suggest to you to verify/check to try and get your link operational without seeing more of your schematic or memory dump.

    Best Regards,
  • Hi Rob,

    Thanks for the hint. I will try it. In case of positive results I'll close that issue here.

    Best regards,

    Heico