• 0

Genesys-2: Ethernet Interface - design migration not working



      I am unable to get Ethernet interface to work on Genesys-2 in my design which is migrated from a Xilinx board.  I have a Microblaze based design that I am trying to port to Genesys-2 Board. This design is working on Xilinx KC705 evaluation board which uses the same Kintex-7 FPGA as Genesys-2. On this design I have Ethernet interface, DDR3 Interface and some other peripherals. We are using Linux for this design. This design was originally developed by another company and was used for evaluating their chip. It was developed on Xilinx evaluation board KC705. This company does not support any other evaluation board. I am hoping to get some help from forum experts to bring-up this design. 

     For this design on Xilinx KC705 board after power up, downloading the bit file and running the SW from *.elf file we can open a PUTTY terminal and issue 'ifconfig' command to check whether the ethernet interface is up and which IP address it got. This works for Xilinx board. But the same does not work for Genesys-2 board, I can issue 'ifconfig' command but I don't see the ethernet interface active. I had looked for pinout differences and made changes accordingly. When I described the symptoms to the original authors of the design they said that because the PHY is different between the two boards I have to update the device tree. Below is the device tree from Xilinx KC705 design. 

Ethernet Device Tree

axi_ethernet: ethernet@40e00000 {

compatible = "xlnx,xps-ethernetlite-1.00.a";

device_type = "network";

interrupt-parent = <&axi_intc>;

interrupts = <1 0>;

local-mac-address = [00 0a 35 00 00 02];

phy-handle = <&phy0>;

reg = <0x40e00000 0x2000>;

xlnx,duplex = <0x1>;

xlnx,include-global-buffers = <0x1>;

xlnx,include-internal-loopback = <0x0>;

xlnx,include-mdio = <0x1>;

xlnx,rx-ping-pong = <0x1>;

xlnx,s-axi-id-width = <0x1>;

xlnx,select-xpm = <0x1>;

xlnx,tx-ping-pong = <0x1>;

xlnx,use-internal = <0x0>;

axi_ethernet_mdio: mdio {

#address-cells = <1>;

#size-cells = <0>;

phy0: phy@7 {

device_type = "ethernet-phy";

reg = <7>;





      PHY on Xilinx KC705 board is Marvell 88e1111. PHY on Genesys-2 is RealTek RTL8211E. The original authors of the design had suggested that at a minimum the line "reg = <7>;' should be changed for Genesys-2. My questions on the forum are below.

1) How should I modify the device tree for Ethernet for Genesys-2 board?

2) Does it seem that just changing the device tree for Ethernet will fix our issue?

3) Any suggestions on how to debug this issue?


     Thank you so much.


Best regards,



Share this post

Link to post
Share on other sites

6 answers to this question

Recommended Posts

  • 0

Unfortunately it is not as simple as copying from one board to another.

First of you must make sure that you check the configuration of the Ethernet IP in the hardware design and make sure it is configured right, compare it to our user demo although I'm not sure if we are using Ethernet lite IP in our design.


The second thing you must do, and this is most likely the issue in your case, make sure that the IP ports in the  XDC are mapped correctly.

From a Linux and device tree perspective if you have the same IPs as the original design for the KC705 (and all the peripherals are present in the Genesys 2) then it should be OK. Basically if only the board changes in your project it's more likely a board specific issue (wrongly mapped XDC, peripherals not present, etc.) rather then a software issue.



Share this post

Link to post
Share on other sites
  • 0



I happen to have both boards and have quite a few successful projects using the Ethernet port on both.

First off you need to understand that the KC705 Ethernet interface is GMII and the Genesys2 is RGMII. This makes the Genesys2 a bit more challenging. Even if you have included the requisite DDR data, control and clocking elements to your port the timing constraints will have to change. Poor timing constraints will break your interface and likely other things as well.

I don't use embedded processors ( except for ARM based ZYNQ ) nor do I use the board design flow so I can only offer hints as to a solution. Also, I don't tend to support triple-speed Ethernet for my projects, just Gigabit speeds.

good luck, with a bit of effort you can succeed.

Edited by zygot

Share this post

Link to post
Share on other sites
  • 0

Hello Jpeyron, Cprian & Zygot:

      Thank you so much for your feedback. Following your suggestions I have completed the steps below.

1) Verified that XDC file and port mapping is correct.

2) Looked at the reference design from Digilent which uses an ethernet port. In this design I looked for timing constraints on RGMII pins. I did not see any specific timing constraints. Other sections of design like the memory interface are working. The only missing piece is the ethernet interface.

3) The Software I am running on our board is provided by Analog Devices. Please refer to the link below for information about the Software


      I am able to build this image and test it. But the ethernet interface does not come up. Link is up but the ethernet interface does not get a valid IP address while going through DHCP. I see the following messages 

".....udhcpc: sending discover

       udhcpc: no lease failing ....."


      As I have mentioned below I have already updated the device tree to match the correct address of Realtek PHY that is used on Digilent Genesys-2 board (Xilinx Board uses Marvell PHY).


     Can you please guide me on how to debug an issue like this? What are the things to check? What can be causing this?

     We are at a crucial stage in our design. Please help us to get a resolution.

     Thank you so much.

Best regards,



Share this post

Link to post
Share on other sites
  • 0

Generally, when you use Vivado IP there are timing constraints embedded in the design. Most people are unaware of them as Vivado isn't too interested in making these easy to find. It's not until you 'roll' your own or try and add conflicting constraints that you learn to look for them. My point is that it's unlikely that with a MicroBlaze design the Ethernet PHY interface is not properly constrained. It's been way too long since I had any interest in rolling a MicroBlaze based project so I can't be of much use.

If you are interested I recently submitted an Ethernet PHY interface test tool to the Project Vault. It's not designed for normal Ethernet hardware/software applications but I do provide code for a Nexys Video Device Under Test project. The Nexys Video and Genesys2 share the same Ethernet PHY RGMII design.

As to how to test your interface I can suggest using ISE ChipScope or the Vivado ILA feature to capture small packets. Start of with a really short one like the ARP packet. You could also write your own code to capture data in and out of the PHY after it's been converted to GMII form.. though I don't have any idea how hard Vivado will make it to break into that level. I am fairly certain that there's a GMI-RGMII bridge somewhere between the PHY and the Microblaze MAC. Another, perhaps better, option is to use your KC705 to send/receive packets and capture native GMII data on that board. These are the ways that I've approached such designs.

Edited by zygot

Share this post

Link to post
Share on other sites
  • 0

Hi Zygot:

     Thank you so much for your feedback. As you had suggested I have tried to focus on debugging at packet level and observe the interfaces. Below are the things I have tried and my observations.

1) MDC/MDIO Interface:

   I probed MDC/MDIO interface of the PHY using an oscilloscope. As the PHY is different (Realtek on Genesys-2 board instead of Marvell on Xilinx board) I wanted to make sure that the change I had made in device tree to show the new device (PHY) address is working correctly. Observing the scope traces I was able to confirm the PHY is being addressed correctly. Software was polling PHY and reading from it's registers. PHY was providing the data. I am not sure whether Realtek and Marvell PHYs have the same register map ( I would think that it would be different). So it would be good if I can make sure that Realtek driver is being used in this Linux image I have build. But I don't know where to look to confirm this.

2) Packet Counters:

     On Linux command line prompt I typed 'ifconfig' to see the packet counters. This command shows the number of Tx and Rx packets along with more detailed information. I was able to see that the number of Tx and Rx packets is 0. In the field for errors I saw the number 4. My understanding is that when the ethernet link comes up DHCP starts and the Genesys-2 board will send a DISCOVER request to the DHCP server. But based on the packet counters it seems that nothing went out from the Ethernet port of Genesys-2.

3) Wireshark Packet Capture:

     To capture Ethernet packets that the other side would receive I had connected an ethernet cable to a PC and ran Wireshark to capture packets. I did not see any packets coming out of Genesys-2 in Wireshark capture.

4) Software Messages:

     I looked for messages in the following two places.

a) Console     

While Ethernet link was coming up I saw the following message on the console.

"xilinx_emaclite 40e00000.ethernet eth0: Link is Up - 100 Mbps/Full - flow control off

udhcpc: sending discover


udhcpc: no lease failing"

b) /var/log/messages file

     Since this file logs events of a Linux system I looked for messages there. I saw the following messages.

"..NETDEV WATCHDOG: eth0 (xilinx_emaclite):  transmit queue 0 timed out"

      I have limited knowledge of device drivers but from these messages it seems that the device driver is not correctly interacting with the hardware.


     Any suggestions on how to debug further from here?

Thank you so much.

Best regards,


Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now