DP83867IS: SGMII Problem with different chip revisions

Hi Nico,

We are looking into this issue and will provide an update by Wednesday of this week. I have reached out to our team internally for more information. 

Thank you,

Nikhil

Thanks for your fast response! Maybe the following information can help: On a low-level, a connection is established. That is, my linux kernel log shows a 1 Gbit/s full-duplex connection with RX flow control. But there is no data transferred. Ifconfig shows zero received packages at the host. The ethernet part of my FPGA design is based on github.com/.../verilog-ethernet

Best,

Nico 

Hi Nico,

I have reached out internally to the appropriate party and will provide additional feedback regarding chip markings when new info is available. 

To clarify, the linux kernel is suggesting a link has established, is this confirmed on the PHY side by reading register 0x1?

Is the schematic the same across all 5 boards? Can the schematic be provided?

Can you provide some details about the setup, Is the current setup only the Xilinx board connected to the DP83867 via MAC interface? What MAC interface is used? What is the desired speed, etc.?  

Thank you,

Nikhil

Hi Nikhil,

here are some answers to your questions:

1.) Unfortunately, I do not know if this is confirmed on the PHY side by reading register 0x1. However, the DP83867IS is connected to the ethernet cable through a Wurth 7499111221A RJ-45 connector. The connector has status LEDs which indicate a 1000BASE-T link. If this is very important for you, I have to come up with a FPGA debug design to read out the registers of the DP83867IS and send it to the host via UART. But I do not have such a design right now..

2.) The schematic is attached.

3.) The setup is as follows:

The Xilinx FPGA (XCVU9P-2FLGA2104) implements a custom MAC [1] that is connected to a Xilinx SGMII IP core [2] which is then connected to the DP83867IS which is then connected via the Wurth 7499111221A RJ-45 connector to the Ubuntu Linux 18.04 host. The desired Speed is 1000Mbit. Linux kernel and the status LED of the RJ-45 connector show a 1000Mbit connection. Exact same setup for all 5 boards. The one board with the DP83867IS TI96I ASL4 G4 chip works like charm, that is, the logic that sits behind the MAC gets UDP packages from the host. I know that because it responds correctly with UDP packages which I receive at the host. Two of the four boards which have a DP83867IS TI95I C1KQ G4 chip sometimes (like 30% of the cases) respond correctly, but only in the first 1 or 2 seconds directly after the bitstream (FPGA logic) was written (flashed) to the FPGA. But then (after ~2 seconds), they never respond again to my UDP packages---seems that something breaks down then (the host and the status LED still report a running 1 gbit connection). The other two boards (also with DP83867IS TI95I C1KQ G4) never ever respond to my UDP packages.

[1] github.com/.../fpga_1g
[2] www.xilinx.com/.../pg047-gig-eth-pcs-pma.pdf

Hope that helps.
Thanks and best,
Nico

4061.phy_schematic.pdf

Hi Nico,

To address your responses.

1. You may look into our USB2MDIO tool, which uses an MSP430 Launchpad to communicate with PHY registers via MDIO/MDC. If this tool looks useful to you, it can be used to access the registers of all of our PHYs.

2. I will review the schematic and provide additional feedback by the end of this week.

3. The RJ45 connector part number 7499111221A has the center taps of the magnetics shorted together. In our datasheet, we provide a diagram for the magnetics without the center taps shorted together. The center taps should be isolated from each other, and separately decoupled to ground. We recommend using the external magnetics part number HX5008NL in our datasheet. Is it possible to isolate the center taps of the magnetics or use the recommended external magnetics?

Additionally, what is the cable length used for this test?

Thank you,

Nikhil

Hi Nikhil,

1.) The USB2MDIO looks useful and I even have a couple of MSP430 launchpads here. However, due to Corona restrictions, I cannot simply enter our office bulding without very good reason. Because of that, I have connected all 5 FPGA boards to a host via Ethernet, UART, and JTAG. So my hope is to solve the problem without physical access to the hardware.

2.) Keep in mind that the board that has a DP83867IS TI96I ASL4 G4 works perfectly and has the same schematic. And today, I asked a friend who owns another VCU118 board to run my FPGA design and it works perfectly as well. The marking on the TI chip of his board is different again. I cannot read it perfectly due to an unsharp picture (see attached file), but it looks like DP83867IS TI 76I A0J3 G4. Beside that, all boards should have the same schematic. So I would say that it is unlikely that it has something to do with the schematic.

3.) This is pretty interesting on its own, since Xilinx sells the VCU118 as one of their top evaluation boards. So it is very strange that they do not use a RJ45 connector that is recommended by TI. However, my gut feeling tells me that this alone whould not be a problem, since two boards work perfectly with the exact same connector. When I first discovered that the four boards do not work as intended, I swaped ethernet cables and host network ports to rule out these things as a source of the problem. Since all other factors (schematic, connector, ethernet cable, etc) are known to work with the board that has the DP83867IS TI96I ASL4 G4 chip, I expect that something in the DP83867IS TI95I C1KQ G4 chip seems to cause the problem. Indeed, it can be a specific combination of things which cause the problem only in conjuction with the DP83867IS TI95I C1KQ G4 but not with the other two DP83867IS chips (mine and that of my friend) I tried out. 

I really hope that someone from TI finds out what the problem is and how it can be fixed.

Thanks again and best,

Nico

Hi Nico,

Thanks for the detailed information and report on what debug steps have already been taken. 

Enabling access to PHY registers will greatly help the debug efforts as we will be able to check the status of the PHY directly. Please let me know if this can be made possible.

In the non-working devices, prior to connecting the cable, can the FLP's be observed on the MDI pairs? If there is no link after the cable is connected, are FLPs still observed?

Thank you,

Nikhil