• State Answer Suggested
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 35 subscribers
  • Views 3344 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.

DP83867E: DP83867 SGMII 1G Ethernet Sync Wrong with Kintex XCKU040

M.sr
Prodigy 70 points
Part Number: DP83867E


Hi

I have XCKU040 Custom Board with DP83867 similar to KCU116,VCU116 connected sgmii 6wire. (sync mode)

i connect 1g pcs/pma ip core to tri mode ethernet ip core. but in AN process i get /bc 4a 01 98 bc a2 01 98/ and sync failed.

sgmii is over LVDS,

when i connect ethernet cable to board, i get /bc 4a 01 98 bc a2 01 98/ and when i remove cable  i get /bc 4a 01 00 bc a2 01 00/

the RX_CTRL is strapped to mode 3.

i think correct sequence is /bc b5 xx xx bc 42 xx xx/. why this sequence is wrong?

Thank you very much for your assistance.

bc.png

  • 0
    TI__Mastermind 26665 points
    Hello M.sr,

    Thank you for using the TI forum. Our product expert will get back to you by Wednesday.
  • 0
    Intellectual 615 points
    Hi,

    I suspect you have a timing or signal integrity problem on the SGMII bus or a timing issue in the FPGA.

    Take a look at IEEE 802.3-2015 Section three, Table 36-1.

    Your /C1/ 2nd byte should be D21.5 (0xB5), which on the wire is

    101010 1010

    But you detect D10.2 (0x4a), which on the wire is

    010101 0101

    These are exactly bit swapped, which I doubt is a coincidence.

    The other byte has a similar symptom.

    Should be D2.2(0x42)
    101101 0101 010010 0101

    Detect: D2.5(0xa2)
    101101 1010 010010 1010

    I would also take a look to see if you are getting running disparity errors. If you are getting these, then your problem is even more likely on the bus, but you might be able to fix it by playing with equalization on the FPGA side.

    Have you taken a scope to your SGMII bus to look at the eye diagram?

    Also, I would try killing the separate SGMII clock and let the PHY recover the clock from the data. That's how I use it, and I get a successful configuration.

    Bob
  • 0 in reply to Bob C
    TI__Mastermind 26320 points

    Hi,

    I agree with Bob comment. AN sequence shall be /C1/C2/Configreg[7:0]/ConfigReg[15:8]. Per interpretation of 01 98: It indicates No full duplex, half duplex is enabled, and Phy sees RF1 fault.

    Please verify the electrical characterisistics of link and suggestion from Bob.

    Regards,

    Geet

  • 0 in reply to Geet Modi
    Prodigy 70 points
    Hi,
    Thank you for your reply and full useful description.
    I tested the board trace up to 13Gb GTX and no any problem.
    I do not think there is a problem with the signal integrity.(16 Layer Board and 100ohm Diff Routing)
    Because I use LVDS, i can not separate SGMII clock in RX(FPGA side).

    Perhaps the problem is about timing in Data,CLK in FPGA input (Setup time/Hold time).
    if timing has a problem, why always repeating the sequence is correct. and K28.5 is true?
  • 0 in reply to M.sr
    TI__Mastermind 26320 points
    Hi,

    DP83867 Trouble shooting guide section 2.10 provides trouble shooting steps. Suggest you step by step verify that each of them is taken care of. Particularly the matched network terminatios on the differential pairs.

    To isolate the issue further, please try the digital loopback on the interface . You can by-pass Auto-neg by forcing both side on full duplex.

    Regards,
    Geet
  • 0 in reply to Geet Modi
    Intellectual 615 points

    In addition to what Geet suggested -

    Have you put a differential probe on the SGMII bus to actually see what's on the wire?  Have you viewed the eye diagram?  If you haven't, then you really should. 

    BTW, we posted some of our SGMII scope traces here:  https://mindchasers.com/dev/hw-sgmii-review

    I previously meant to write that you should try to have the FPGA recover the clock from the data, so it's not using your diff clock for timing.  I would think that configuring the FPGA to eliminate the use of the separate SGMII clock is an option, but it would need a CDR PLL inside to do. 

    Good luck,

    Bob

  • 0 in reply to Bob C
    Prodigy 70 points

    Thank you for your guidance.

    Unfortunately, my scopes do not exceed 300 MHz.

    In these few days I checked out a lot of timings,placement and routing in FPGA. There was no problem with the FPGA.

    FPGA code Automatically adapts the Clock phase to sample the right point.

    I've read a lot of posts from the xilinx site. please see these posts:

    https://forums.xilinx.com/t5/Networking-and-Connectivity/TEMAC-autonegotiation-in-SGMII-mode/td-p/23672

    https://forums.xilinx.com/t5/Networking-and-Connectivity/V5-Embedded-Emac-SGMII-Unknown-Output/td-p/57685

    https://forums.xilinx.com/t5/Networking-and-Connectivity/vc707-SGMII-RJ45/td-p/394721

    the sequences is K28.5, B5, 01, 98, K28.5, 42, 01, 98  if the ethernet cable is connected and K28.5, B5, 00, 00, K28.5, 42, 00, 00 if the cable is not connected.

    Everything is like my case, except for the second byte. in my case B5 replaced with 4A, and 42 replaced with A2.

    Why are only the second byte is wrong? I do not think the problem is with timing.

  • 0 in reply to M.sr
    Intellectual 615 points
    M.sr,

    Without a scope and a diff probe, you'll need to rely on trial and error until you figure this one out.

    As I pointed out in my first reply to you, the 10 bits (8b/10b) that you are receiving on the line are very close to what you should actually receive. This is what led me to believe it was a timing / signal integrity issue, and I still suspect this. It could be inter-symbol interference, where the previous bit(s) interfere with the current one. Keep in mind that a K28.5 contains a comma that is used by the receiver for synchronization.

    If the FPGA supports equalization / filtering of the received data, then I would play around with this, too.

    Also, maybe look at the logic & timing constraints in your FPGA that may interfere with clocking the byte that is received after the K code (K28.5).

    However, in the end, if this is a product that you're going to ship, you really should put a scope on the SGMII / SERDES lines and take a good look at the quality of the signals and make sure you test all your corner cases ( temp, voltage, etc. ).

    Hope this helped a little. Good luck and please let us know the root cause once you figure this out.

    Bob