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.

DP83867CS: SFD and CRC errors seen with Cisco Catalyst 9300 switch

Part Number: DP83867CS

Hello,

We are seeing errors with the Cisco 9300 10G or 2.5G copper ports (negotiated to 1Gbps) now that we have switched to your DP83867CS PHY.  We do not see these errors with our original QCA 8031 PHY that we migrated from. 

We see the error behavior change if we put different settings into the Viterbi idle threshold register.  The best behavior is with that register set to 2.  The default of 5 shows the most errors.  No setting, however, will avoid these errors. 

I pull stats from the following register/fields and see the errors reported:

RXFSTS bit7: SFD_ERR
RECR [15:0]: RXERCNT
STS1 [7:0]: 1000Base-T IDLE ERROR COUNTER

With the idle threshold set to 4:

The idle error counter is not incrementing in the stats.  The RXERCNT seems to increment the same as the MAC ethtool rx_crc_errors count and the rx_drop count that is reported by ethtool roughly – just a few packets higher than the sum.  The SFD_ERR bit is showing, as well as the BAD_CRC status bit in the same register.

With the idle threshold set to 2:

The idle error counter does not increment in the stats.  The RXERCNT seems to increment with the ethtool rx_crc_errors count (no rx_drop counts reported) that is reported by ethtool.  The SFD_ERR is NOT showing, but the  BAD_CRC status bit is set in the same register.

So it appears the PHY part is detecting these errors we see.  The rx_drops seem to follow SFE_ERR being set, and the rx_crc_errors seem to follow the BAD_CRC bit being set, and the frame counts roughly match eth ethtool stats.

Have you had this experience in interoperating with a Cisco 9300 switch?  Other switches thus far do not exhibit the issues and the stats are clean.  Please advise.

Thanks,

Dave

  • Hi Dave,

    Do you have a register dump for the DP83867 as well as a snapshot of the schematic for the PHY?

    Thanks,

    Cecilia

  • As requested:

    Here is a schematic clip:

    Here is a register dump:

    status_reg_1: 0x7800
    rx_status: 0x18
    rx_error: 0x0E
    reg0x0: 0x1140
    reg0x1: 0x796D
    reg0x2: 0x2000
    reg0x3: 0xA231
    reg0x4: 0x1E1
    reg0x5: 0xC181
    reg0x6: 0x6D
    reg0x7: 0x2001
    reg0x8: 0x4800
    reg0x9: 0x300
    reg0xa: 0x7800
    reg0xb: 0x00
    reg0xc: 0x00
    reg0xd: 0x401F
    reg0xe: 0x00
    reg0xf: 0x3000
    reg0x10: 0x5848
    reg0x11: 0xAC02
    reg0x12: 0x00
    reg0x13: 0x00
    reg0x14: 0x29C7
    reg0x15: 0x0E
    reg0x16: 0x00
    reg0x17: 0x40
    reg0x18: 0x6150
    reg0x19: 0x4444
    reg0x1a: 0x02
    reg0x1b: 0x00
    reg0x1c: 0x00
    reg0x1d: 0x00
    reg0x1e: 0x202
    reg0x1f: 0x00
    reg0x25: 0x400
    reg0x2d: 0x00
    reg0x2e: 0x221
    reg0x31: 0x1090
    reg0x32: 0xD3
    reg0x33: 0x00
    reg0x37: 0x01
    reg0x43: 0x7A0
    reg0x53: 0x2052
    reg0x55: 0x00
    reg0x6e: 0x804
    reg0x6f: 0x100
    reg0x71: 0x00
    reg0x72: 0x00
    reg0x7b: 0x5DC
    reg0x7c: 0x7D
    reg0x86: 0x77
    reg0xc6: 0x00
    reg0xd3: 0x00
    reg0xe9: 0x9F22
    reg0xfe: 0xE721
    reg0x12c: 0xC2D
    reg0x134: 0x1080
    reg0x135: 0x00
    reg0x136: 0x00
    reg0x137: 0x00
    reg0x138: 0x00
    reg0x139: 0x00
    reg0x13a: 0x00
    reg0x13b: 0x00
    reg0x13c: 0x00
    reg0x13d: 0x00
    reg0x13e: 0x00
    reg0x13f: 0x00
    reg0x140: 0x00
    reg0x141: 0x00
    reg0x142: 0x00
    reg0x143: 0x00
    reg0x144: 0x00
    reg0x145: 0x00
    reg0x146: 0x00
    reg0x147: 0x00
    reg0x148: 0x00
    reg0x149: 0x00
    reg0x14a: 0x00
    reg0x14b: 0x00
    reg0x14c: 0x00
    reg0x14d: 0x00
    reg0x14e: 0x00
    reg0x14f: 0x00
    reg0x150: 0x00
    reg0x151: 0x00
    reg0x152: 0x00
    reg0x153: 0x00
    reg0x154: 0x00
    reg0x155: 0x00
    reg0x156: 0x00
    reg0x157: 0x00
    reg0x158: 0x00
    reg0x159: 0x00
    reg0x15a: 0x00
    reg0x15b: 0x00
    reg0x15c: 0x00
    reg0x15d: 0x00
    reg0x15e: 0x00
    reg0x15f: 0x00
    reg0x160: 0x00
    reg0x161: 0x0C
    reg0x170: 0xC0F
    reg0x172: 0x00
    reg0x180: 0x752
    reg0x190: 0x00
    reg0x191: 0x00
    reg0x192: 0x00
    reg0x193: 0x00
    reg0x194: 0x00
    reg0x195: 0x00
    reg0x196: 0x00
    reg0x197: 0x00
    reg0x198: 0x00
    reg0x199: 0x00
    reg0x19a: 0x00
    reg0x19b: 0x00
    reg0x19c: 0x00
    reg0x19d: 0x00
    reg0x19e: 0x00
    reg0x19f: 0x00
    reg0x1a0: 0x00
    reg0x1a1: 0x00
    reg0x1a2: 0x00
    reg0x1a3: 0x00
    reg0x1a4: 0x00
    reg0x1d5: 0xF500

  • Hello - any update?

  • Hi David,

    Thanks for sending over the schematic and registers. I am still investigating the DP83867 interoperability with a Cisco 9300 switch.

    Thanks,

    Cecilia

  • Hi David,

    I'm having trouble reading the schematic properly due to the quality of the image. Could you make sure the magnetics are set properly per the datasheet and schematic recommendations? 

    Another thing is: could you perform an analog loopback and a reverse loopback and see if you are getting errors?

    Thanks,

    Cecilia 

  • All the operation is fine as long as it is not a 9300 switch, so the loopback modes will surely work as that only goes to the phy.

    The only difference in the magnetics is that the transformer we have has a common center tap to the 4 pairs on the system side.  But again this works fine with every other switch and any differences in line side DC conditions are isolated by the transformer.  Also, the fact that we can reduce errors by changing the viterbi idle detector, seems to indicate it is not a general random bit error problem for an electrical issue but something to do with the idle symbols at the ends of the frames.

    Can you try an eval board perhaps against a 9300 to see if it shows errors for you?  Or send me a loaner system with this phy that I can compare against and send back to you?  If it is clean then it would point to electricals in our system vs. a general issue.

  • Hi David,

    Running the different loopback tests helps us understand if it is an issue coming from the cable side or from the MAC side from a debug perspective. I can look into how we could get our hands on a 9300. 

    Thanks,

    Cecilia

  • The loopback modes back to the MAC did not show errors.  The remote loop was not possible with the 9300 as far as we can tell.

    Have you been able to try with a 9300.  If you like you can send me a different test platform and I can run packets through the 9300 here and check errors, then send it back to you.

  • In addition, in order to rule out the fact that our transformer center taps on the PHY side were tied together to a single cap to ground, we reworked a board to separate the center taps.  We still see the CRC errors in this case with the 9300, and not with other switches.  So this appears to be a phy issue with these higher speed copper ports on that Cisco 9300.  Unless you have other ideas we will have to go to a different PHY.  It seems to be related to frame delimiting as slowing down the pace of packet seems to lower the CRC error percentage.

  • Hi David,

    When you separated the center taps did you use 0.1uF caps to separate them? Please review our troubleshooting guide to see our typical connections on our magnetics

    http://www.ti.com/lit/an/snla246a/snla246a.pdf

    Cecilia

  • Yes, I used 4 of the 0.1uF caps, one to each center tap as shown in the figures.

  • Hi David,

    When you mentioned that you tested all the loopback functions you only mentioned the loopbacks going back to the MAC. Were you able to test reverse loopback which would loop back on the analog side with the link partner? Please let me know if you saw any errors on that. 

    Thanks,

    Cecilia

  • How is that possible when the only thing that sees the error is a Cisco 9300?  How can I make a Cisco switch send to the phy when it is in loopback?

  • Hi David, 

    My apologies, perhaps there was miscommunication as I am not too familiar with this product. Is the Cisco 9300 connected as a link partner to the PHY on the MDI side? If it is, you can set the PHY into reverse loopback and still check for errors.

    Thanks,

    Cecilia