Genesys2 Ethernet Problem

[stefano134 0]

hello,
i'm trying to test the ethernet port of my genesys 2 board using the demo 'IwIp Echo Server', as shown in the tutorial: 'https: //reference.digilentinc.com/learn/programmable-logic/tutorials/genesys-2-getting-started-with-microblaze-servers/start ' but i can't get it to work. i'm experiencing some anomalies. first of all after connecting the board to the pc the led 'Link' doesn't stay on but it blinks, and then vitis gives me some warnings for the microblaze that i don't know if i can ignore. the only thing different from the tutorial i did was to add a clock and move the addresses of the axi ethernet block. i think i have to change manually the address on echo server, but on the codes i don't see any address written.
does anyone know how to fix this?

 

[stefano134 0]

hangs here

Edited February 7 by stefano134

[zygot 226]

I see that you're back after thinking that the your design was working. Well this is a good lesson because 'working' is a slippery thing to define.

The basis of Ethernet is the PHY interface. Create two ILAs in your design to capture Tx and Rx data. They are different clock domains and need separate ILA instantiations. This will tell you if you at least are getting reasonable Rx data. A complication is that for the Genesys2 the PHY uses RMII so the data is DDR. In my designs I usually have a GMII bridge so that I can see 8-bit data easily.

I do a lot of work using the Ethernet PHY in my designs so I can tell you that debugging this interface isn't easy. So I have a couple of designs for multiple platforms that I know work and can test Ethernet PHY designs on other boards. It's nice if you have something to connect to the other end of your Ethernet cable that echoes back whatever it receives, or at least issues a small known packet like an ARP request periodically. If you have a good Ethernet Echo appliance you can exercise your hardware with gigabytes of data and a wide range of packet payload sizes.

The bad news is that even if you get your design to the point where you can write your DDR with data sent by an external Ethernet connected source and read it back on that source "working" is still more illusion than fact. You can push this toward the fact end my heavily exercising the hardware under a lot of conditions.

I forgot to mention this but if your design has no timing constraints you can end up with a perfect timing score of 0 and an implementation that has no chance of working on hardware. Indeed, be careful of a timing score of 0 in Xilinx designs of any complexity... it might be a false sense of security.

[edit] I forgot to mention this but having two FPGA boards for debugging Ethernet where one is a 'golden' implementation is the best in my experience. You might be able to use something like a Raspberry Pi 4 as an alternative though writing a raw Ethernet application that's useful is a challenging project on its own.

[edit2] After revisiting my answer I had a few more thoughts. Debugging the combination of HW/SW is challenging, even when you are the person doing both. The easy but not necessarily quickest way to do this is to verify the HW first as I explained above.  Once you have good confidence in the hardware resolving SW issues involves fewer unknowns. It's not uncommon to have both in a new design.

I don't use MicroBlaze but with ZYNQ the processor cores are fast enough to cause AXI bus faults depending on how you do your SW. Figuring this all out in the tools is not always straight forward. A clue is whether or not you need to reboot, reconfigure in order to continue using the platform, at least this is my experience with ZYNQ. Still, I'd concentrate on verifying that the HW is robust before trying to do  significant SW design.

One more thought. After you create your basic BSP find the files that define your HW addresses. If you are using the standalone libraries to access HW make sure that they support your HW. Sometimes, the demo applications require a loopback HW design in order to work.

Edited February 8 by zygot

[stefano134 0]

thanks always for the reply
I found that the problem was due to an error in the xilinx library 'lwip211_v1_3', in fact I redid the project with the version of vivado 2016.4 and there, having an older version of the library works. 

[zygot 226]

Thanks for the update. Sorry that I didn't seem to have any useful advice. I still use Vivado 2016.4 on my WIn7 box. There are a number of things that seem to work better in that version than some recent versions of the tools.