We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Observer jameswarnock
Registered: ‎10-18-2013

VCU118 SGMII Ethernet

Jump to solution

I have been attempting to get ethernet working on the VCU118 for some time now. I have read many forum posts, answer records and datasheets and I just can't seem to get it working.


This is a rev 1.1 VCU118 with a Xilinx AXI Ethernet Subsystem 7.1 IP block. I am using Vivado 2017.3 which we got early access to hoping the bug fix in the ethernet drivers would solve this problem, but it hasn't helped. I assume the bug fix is the procedure described in AR #69494. The hardware is configured for 1Gb and SGMII over LVDS. I am running custom software (with several header files extracted from the HDF exported by Vivado) using LwIP on a MicroBlaze processor. The software listens on port 58713 for incoming connections and has a static IP address. I have an ethernet cable directly connecting the VCU118 RJ45 jack to my computer which also has a static IP. 


When the software runs, I can connect (SYN->SYN/ACK->ACK) to port 58713 from my computer and send data (PSH/ACK). Output to the console shows that the connection is received and the response is generated and written to the socket. The DMA retrieves the generated packet and streams it to the Ethernet subsystem. Finally, the ethernet subsystem asserts the Transmit Complete interrupt (TxCmplt). However, the packet never makes it back to my computer and I can never connect again. After each subsequent packet re-transmission by my computer I can see the software attempting to resend the response, but the computer still never receives anything. Running Wireshark shows no packets from the VCU118 (after the SYN/ACK from the initial connection).


I tried adding an ILA to the MM2S AXI Streaming interface from the DMA to the Ethernet Subsystem. With the ILA, I can see packets being sent to the Ethernet block from the DMA that don't arrive at my computer. I wanted to use an ILA to monitor the SGMII TX lines, but haven't yet been able to make that work.


Both the TI PHY and the SGMII core are configured for auto-negotiation and they successfully negotiate to 1000Mbps as reported by the SGMII core register 5.


I found the LwIP Echo server example code in the SDK and tried that. I had to change the FPGA design to allow the DMA engine to do unaligned transfers (selected "Allow Unaligned Transfers" on both the Read and write channels and selected "Use Rxlength In Status Stream" in the DMA configuration). When I load the example design, the echo server responds correctly. I modified the example code to use a static IP. I can connect to port 7 using telnet and anything I send gets echoed back. This seems to prove that the hardware works and that that the FPGA design is functional.


I then modified the example code to log all register writes to the TI PHY or the AXI Ethernet address space. Then I modified my custom code to write the same values to the same registers. The following is the PHY/MAC setup process that my code now uses:


  1. Write 0x1000FFFF to Tri Mode Ethernet MAC register 0x404 (Receiver Configuration Word 1) to enable the receiver
  2. Write 0x60000000 to MAC register 0x40C (Flow Control Configuration Word) to enable flow control on RX and TX channels
  3. Write 0x00000000 to MAC register 0x708 (Frame Filter Control) to disable promiscuous mode
  4. Write 0x00000000 to AXI Ethernet 0x000 (Reset and Address Filter) to disable all filtering.
  5. Write the device's MAC address to MAC registers 0x700 and ox704
  6. Write 0x00000053 to MAC register 0x500 (MDIO Setup) to enable the MDIO at a clock rate of 2.5MHz
  7. Write 0x1040 to SGMII core register 0x0 (Control) to enable Gigabit and Auto-negotiation
  8. Write 0x4000 to TI PHY register 0xD3 (SGMIICTL1) to enable 6-wire SGMII
  9. Write 0x1140 to TI PHY register 0x0 (BMCR) to enable Gigabit, Auto-negotiation and full-duplex
  10. Write 0x29C7 to TI PHY register 0x14 (CFG2) to enable speed optimization at 10Base-Te, SGMII auto-negotiation, enhanced speed optimization, 4 speed optimization retries and low interrupt polarity
  11. Write 0x0000 to TI PHY register 0x32 (RGMIICTL) to disable RGMII
  12. Write 0x0800 to TI PHY register 0x10 (PHYCR) to enable SGMII
  13. Write 0x1170 to TI PHY register 0x31 (CFG4) to set the SGMII auto-negotiation timer to 11 ms and perform the software workaround mentioned in AR #69494 because the TI PHY is not strapped to mode 3.
  14. Write 0x1340 to SGMII core register 0x0 (Control) to enable Gigabit, Auto-negotiation and full-duplex and restart auto-negotiation
  15. Read SGMII core register 0x1 (Status) until bit 5 goes high indicating auto-negotiation has completed
  16. Read SGMII core register 0x5 (SGMII A-Neg LP Ability) until bit 15 goes high indicating the SGMII link is up
  17. Read SGMII core register 0x5 (SGMII A-Neg LP Ability) bits [11:10] to determine the negotiated speed
  18. Write MAC register 0x410 (MAC speed configuration word) with the appropriate setting based on the speed determined in the previous step.
  19. Write 0x38 to AXI Ethernet register 0x14 (Interrupt Enable Register) to enable frame rejection, FIFO overflow and transmission completion interrupts.

My code with this PHY setup procedure still fails like before. I can connect once and send data, but the response never makes it to the ethernet cable.


Do you see anything I am missing? Is there more information I should provide?

0 Kudos
1 Solution

Accepted Solutions
Observer jameswarnock
Registered: ‎10-18-2013

Re: VCU118 SGMII Ethernet

Jump to solution

Well, I feel stupid. The problem was the unaligned DMA transfers. Using my software with the FPGA design that had unaligned transfers fixed the problem. Without unaligned transfers, I saw no errors from the DMA and I saw streaming DMA operations succeed so I assumed everything was fine. I guess the lesson is: check your assumptions. 

0 Kudos
3 Replies
Observer jameswarnock
Registered: ‎10-18-2013

Re: VCU118 SGMII Ethernet

Jump to solution

I thought maybe I should list the resources I have read and why they haven't helped me solve this problem.


  1. Forum Posts
      1. I am not entirely sure what the problem is in this post, but it doesn't sound like mine
    2. SGMII 1G Ethernet 16.0 to PHY on the board
      1. This one is about problems routing the design. My design is routed and mostly running.
    3. Kintex XCKU040 SGMII 1G Ethernet Sync Wrong
      1. This is about auto-negotiation failing. My design auto-negotiates successfully. Also, that post has no answer.
    4. PCS/PMA or SGMII v16.1 for VCU118
      1. This is about the MDIO interface and the MDIO interface in my design is functional.
  2. Answer Records
    1. AR #69494: VCU118 / KCU116 - How to bring up the SGMII PHY
      1. DP83867 register settings to enable SGMII. Already applied.
    2. AR #39460: LogiCORE IP V5 Tri-Mode Ethernet MAC - Debugging SGMII link issues
      1. Not many of the points here were applicable. I know the hardware works and VCU118 uses LVDS instead on transceivers.
    3. AR #68277
      1. This is about ethernet drivers for the VCU118 not working prior to Vivado 2017.3. I am assuming that the change made in 2017.3 is the software workaround described at the end of AR #69494. My design does not use the full drivers generated by 2017.3 only some of the header files. I did a recursive diff of the BSP directories generated by 2017.2 and 2017.3. The only significant and applicable change I noticed was the software workaround.
  3. TI (DP83867) Resources
    1. C6678 DSP- DP83867 PHY SGMII Link up Issue
      1. The solution here was to change the strapping. I know that the my hardware can be made to work so somehow it is possible to workaround the invalid strapping in software (which I think I have already done).
    2. DP83867 Troubleshooting Guide
      1. Most of the suggestions in this guide are about validating the hardware. Since I know my hardware can work, those steps are irrelevant. The guide does recommend reading certain registers (0x0, 0x1, 0x4, 0x5, 0xA, 0x10, 0x11) to check for problems there. I have read those registers and they all contain valid--non-error--values.
    3. DP83867 - no SGMII link
      1. The problem in this post is that auto-negotiation on the SGMII link fails. In my design, auto-negotiation on bothe the MII and the MDI sides succeeds.

That is all that I can remember. I probably missed some, but this is a good selection.

Observer jameswarnock
Registered: ‎10-18-2013

Re: VCU118 SGMII Ethernet

Jump to solution

Some more information:


Here are some of the register values I have read from the PHY. These values are all the same between the example design and my custom design.

0x00 (BMCR): 1140 
0x01 (BMSR): 796D 
0x04 (ANAR): 01E1 
0x05 (ANLPAR): CDE1 
0x09 (CFG1): 0300 
0x0A (STS1): 3800 
0x10 (PHYCR): 0800 
0x11 (PHYSTS): AC02 
0x13 (ISR): 0000 
0x14 (CFG2): 29C7 
0x31 (CFG4): 1170 
0x32 (RGMII): 0000 
0x37 (SGMII ANEG): 0001 
0x38 (?): 0001 
0xD3 (SGMII): 4000 
0xDC (?): 3800


Since these are the same between the working code and the non-working code, I doubt there is anything to learn here. However, one thing to note. According to resource 3.3 listed above, register 0x38 is the value of tx_config_Reg[15:0]. According to table 1 in this Lattice Semiconductor document: bit 15 represents the link status (1=up, 0=down), bit 12 represents the Duplex mode (1=full, 0=half) and bits [11:10] represent the speed (2'b00=10Mb, 2'b01=100Mb, 2'b10=1Gb, 2'b11=Reserved). The value I read from that register seems to indicate the link is down even though other registers show that the link is up.

Observer jameswarnock
Registered: ‎10-18-2013

Re: VCU118 SGMII Ethernet

Jump to solution

Well, I feel stupid. The problem was the unaligned DMA transfers. Using my software with the FPGA design that had unaligned transfers fixed the problem. Without unaligned transfers, I saw no errors from the DMA and I saw streaming DMA operations succeed so I assumed everything was fine. I guess the lesson is: check your assumptions. 

0 Kudos