Zybo Z7 Ethernet project

[Oscar O.]

Hi, 

On the Zybo Z7 resource page there are several project examples. Do any of them use the ethernet port on the board to send and receive data to the programmable logic in the FPGA?. We are doing a project which requires access to the registers and memory in the programmable logic portion of the chip containing our design via an ethernet connection.

Resource page is at:

https://digilent.com/reference/programmable-logic/zybo-z7/start?redirect=1

 

[artvvb]

Hi Oscar,

Please review this guide, "Getting Started with Zynq Servers", which runs through setting up one of AMD's TCP echo server example: https://digilent.com/reference/programmable-logic/guides/zynq-servers. This will get data into and out of the PS, after which PS-PL communication can be implemented using EMIO peripherals, AXI IP such as GPIOs or custom modules, or DMA. Digilent doesn't currently provide a demo for the Zybo Z7 that integrates every part of this communication chain.

Thanks,

Arthur

[Oscar O.]

Hi Arthur,

I went to the link and it says software needed is 2023.1 but then it starts talking about 2023.2 and how that was a big change. I have 2023.2 installed do I need to go back and install 2023.1?

Software

Xilinx Vivado 2023.1 software suite

If the Vivado Suite has not been installed, please review the following installation guide Installing Vivado, Vitis, and Digilent Board Files

Substantial UI changes in Vitis 2023.2 have changed much of the specifics of how to work with projects and this guide has not yet been updated. For a detailed rundown of changes, check out Adam Taylor's post about it on the adiuvoengineering blog.

Edited March 22 by Oscar O.

[artvvb]

The quoted text is intended to mean that the guide is unlikely to work as written with 2023.2. 2023.1 should work fine as it's what it was written for. We've updated the text in the infobox to be more clear.

[Oscar O.]

Do you have the power supply (wall wart) that is needed to power the board? Part number...

[Oscar O.]

One other question.. once I build a project do I use one of these to program it

(https://www.digikey.com/en/products/detail/amd/HW-USB-II-G/1825189?utm_adgroup=&utm_source=google&utm_medium=cpc&utm_campaign=PMax Shopping_Product_Low ROAS Categories&utm_term=&utm_content=&utm_id=go_cmp-20243063506_adg-_ad-__dev-c_ext-_prd-1825189_sig-CjwKCAjw5ImwBhBtEiwAFHDZx-AT2Z8lWS5FVt56I_ORq8PepdvRzQMlzcW-KvcUU0TdpWGiMMaj9xoCJ3sQAvD_BwE&gad_source=1&gclid=CjwKCAjw5ImwBhBtEiwAFHDZx-AT2Z8lWS5FVt56I_ORq8PepdvRzQMlzcW-KvcUU0TdpWGiMMaj9xoCJ3sQAvD_BwE).?

 Although the header on the above has two rows vs the zybo z7 user manual says J13 is one row only. Not sure if it is compatible.

So what is the best way to program from Vivado on my laptop to the board.

 

[artvvb]

Unless you have a particularly power-hungry demo, you can power the board over USB from your laptop - that said, this supply is compatible: https://digilent.com/shop/5v-2-5a-switching-power-supply/. You can also program it directly over USB via J12. Installing Vivado should install the drivers that are needed to talk to it. I'd recommend you run through the reference manual and some of the tutorials listed on the board's resource center: https://digilent.com/reference/programmable-logic/zybo-z7/start.

[Oscar O.]

Hi Arthur,

  I was able to generate the project following the example at https://digilent.com/reference/programmable-logic/guides/zynq-servers?_ga=2.132423246.1936083739.1710846565-1774928201.1710252575/. Cant test is as we just ordered the boards.

One issue I keep thinking of is the fact that we have packets that are about 1400 bytes big coming in every 300 hz or so on a serial interface then we have to take them and send it out on the ethernet port. Same going the other say.

In the above design it looks like the PS is able to receive a packet (which I am assuming is one character) and echo it back via the echo.c:

    err = tcp_write(tpcb, p->payload, p->len, 1);

As the comment in the code says, we assume that the payload is < TCP_SND_BUF.

I am not sure the PS can handle that kind of rate???

I was reading the Zynq 7000 SoC Technical Reference Manual (https://docs.amd.com/r/en-US/ug585-zynq-7000-SoC-TRM/Zynq-7000-SoC-Technical-Reference-Manual) and in there it has the following block diagrams of the Ethernet Controller it seems I don't have access to the buffers but only to the GMII pins that interface, see diagrams below.

What I need to do is grab the packet of data from the ethernet connection and send it to the PL so I can serially send it out. Going the other way, receive the serial data in the PL and send it to the host computer via the ethernet interface. It seems to do that I need to be able to access the AHB port (see diagram 2 below) or at least the buffers if they are big enough to put and grab data from? From what I can see in the second diagram the PL is not able to access that?

Any help would be appreciated.

 

[artvvb]

2 hours ago, Oscar O. said:

One issue I keep thinking of is the fact that we have packets that are about 1400 bytes big coming in every 300 hz or so on a serial interface then we have to take them and send it out on the ethernet port. Same going the other say.

I haven't benchmarked the TCP echo server example, but this sounds plausible to implement. Packets for the echo server unmodified might be 1 byte, or however large the software creating the packets makes them (a serial terminal you're typing into seems like it would likely send one byte at a time), but the raw ethernet packets max out only a little smaller than 1500 bytes. This blog post also extends the echo server example to send more than a byte at a time, using a python script on the PC side.

2 hours ago, Oscar O. said:

What I need to do is grab the packet of data from the ethernet connection and send it to the PL so I can serially send it out. Going the other way, receive the serial data in the PL and send it to the host computer via the ethernet interface.

Once data is received in the PS & DDR, you could use AXI DMA or a similar mechanism to move it to PL. Note that AXI DMA is an IP that is added to a block design, and not the hard DMAs built into the Zynq PS (which I believe are much less performant, could be wrong). There are various demo projects around, you could check out the Zybo's DMA Audio demo, which uses DMA to move audio data between DDR (where PS can access it) and an I2S interface. I've also written about DMA a fair amount on the forum, this thread being one example:

There was another user building a similar system in this thread:

 

[Oscar O.]

Ok, lots of material to go over here, thank you... have to take it all in 😬. Will bring up the audio project to have a look at the DMA portion. 

Have you ever simulated the Zynq server project? Not sure if there is something that would mimic an ethernet connection to the Z7's FPGA that could send data to it and receive it from the board??? Is there something like that around? I am a firm believer of simulating the design before going to the actual hardware.

I have simulated an FPGA using a MicroBlaze, including the DDR3 interface as I found some models of the DDR3 memory we were using. The Microblaze code was put in via a LEF file generated in Vitis. I was never able to run it within Vivado, I used what is generated when I tried doing a behavioral sim and then had my own simulation command script to compile and run.

[Oscar O.]

I downloaded the Audio zip files and followed the instructions for importing the project... however I got the error below. Mind you I am using Vivado 2023.1. Could that be the problem....I cant install every version of Vivado as I had a hard time getting 2023.1 installed due to space issues

[artvvb]

On 4/2/2024 at 10:40 AM, Oscar O. said:

Have you ever simulated the Zynq server project? Not sure if there is something that would mimic an ethernet connection to the Z7's FPGA that could send data to it and receive it from the board??? Is there something like that around? I am a firm believer of simulating the design before going to the actual hardware.

I have not. There are some AMD resources on simulating the Zynq PS, but I'm not sure if they cover external HW like Ethernet or if they're primarily for simulating software in conjunction with FPGA gateware.

On 4/2/2024 at 11:21 AM, Oscar O. said:

I downloaded the Audio zip files and followed the instructions for importing the project... however I got the error below. Mind you I am using Vivado 2023.1. Could that be the problem....I cant install every version of Vivado as I had a hard time getting 2023.1 installed due to space issues

I'm sure "It works on my machine" isn't the most helpful, but I was able to download the 2022.1 Vitis archive for the Zybo Z7-20 variant of the DMA Audio demo, open it in 2023.1, and run it in hardware. Which download did you use?

[Oscar O.]

Hi Arthur,

  When I powered up the board I think it started running the default demo program as led's were blinking etc.

I then build the echo server, brought up a putty window and did RunAs→Launch Hardware(Single Application Debug).

It came back with the following and the LEDs have frozen. I am not sure what is the problem and how to get the ethernet server to run.

One more detail... it does say programming FPGA then it gives the error below.

Edited April 5 by Oscar O.

[artvvb]

Please try switching the board into JTAG boot mode by moving jumper JP5 and power cycling it.

[Oscar O.]

Ok changing the jumper worked. 

I have a few more questions. On the server project if instead of a terminal to send one character at a time I have a piece of python code that could send a block of data...would that block be echoed back or this only works one character at at time? I take it the characters or block of data are being received are put into a buffer?? is that buffer in the DDR3 mem?

If the buffer/data is not stored into DDR3, how can I make it so it will store it in DDR3?... as you may remember you mentioned that to get the data from PS to PL I could do a DMA from DDR3 to PL

Reading through some of the code I keep seeing tcp_*** is the ethernet protocol being used to send and receive data above a TCP protocol? If it is....is there a server example using UDP? Or how can I change it to UDP?

Also, if I wanted to have the server application (or any other) without having to have the board hooked up to the programming uart port can the fpga boot off the SD card? If yes, what are the steps to get the files into an SD card.

Edited April 9 by Oscar O.

[artvvb]

4 hours ago, Oscar O. said:

On the server project if instead of a terminal to send one character at a time I have a piece of python code that could send a block of data...would that block be echoed back or this only works one character at at time?

The block should be echoed back. If the TCP example receives a block of characters at once, it sends them all back at once. To confirm, you could print p->len in the recv_callback function.

4 hours ago, Oscar O. said:

I take it the characters or block of data are being received are put into a buffer?? is that buffer in the DDR3 mem?

Yes, the echo server includes an internal buffer, which is located in DDR - all buffers and variables in the software application should be in DDR, you can check the linker script (lscript.ld) to confirm.

4 hours ago, Oscar O. said:

Reading through some of the code I keep seeing tcp_*** is the ethernet protocol being used to send and receive data above a TCP protocol? If it is....is there a server example using UDP? Or how can I change it to UDP?

I don't have personal experience with the UDP API. There are several template applications that should use it, but potentially no echo server example.

4 hours ago, Oscar O. said:

Also, if I wanted to have the server application (or any other) without having to have the board hooked up to the programming uart port can the fpga boot off the SD card? If yes, what are the steps to get the files into an SD card.

Please review this guide: https://digilent.com/reference/programmable-logic/guides/zynq-baremetal-boot.

[Oscar O.]

So there is a UDP sever and client. Does the echo server use both a client and server or just a tcp server to do receive and send back data to the host computer via ethernet? In other words do I use both the udp server and client or just the server???

Which microSD card size do you recommend and class do you recommend... do you have a preferred brand?

You said: "you can check the linker script (lscript.ld) to confirm."  Are the lines below the ones that define the buffer area?

/* Define Memories in the system */

MEMORY
{
   ps7_ddr_0 : ORIGIN = 0x100000, LENGTH = 0x3FF00000
   ps7_qspi_linear_0 : ORIGIN = 0xFC000000, LENGTH = 0x1000000
   ps7_ram_0 : ORIGIN = 0x0, LENGTH = 0x30000
   ps7_ram_1 : ORIGIN = 0xFFFF0000, LENGTH = 0xFE00
}
 

So when the Vitis project is compiled it understands the hardware it is dealing with and sees that there is a DDR3 memory it can use to store information... is that a accurate description?

 

Going back to the audio project, I see that the block that interfaces with the external codec (d_axi_i2s_autidio) hooks up to the DMA block using the axi..the axi_interconnect block then is hooked up to the ZynQ7 via the S_axi_HP0 port. How does the dma know where the microphone sound buffer resides in the DDR3 memory (location)? Is this a parameter that gets programmed to it?? Just trying to see how it all fits together. Sorry for all of the questions I have never done a project with Zynq processor and Vitis.

Edited April 10 by Oscar O.

[artvvb]

9 hours ago, Oscar O. said:

So there is a UDP sever and client. Does the echo server use both a client and server or just a tcp server to do receive and send back data to the host computer via ethernet? In other words do I use both the udp server and client or just the server???

I believe the echo server just implements a server - the serial console or python script acts as client.

9 hours ago, Oscar O. said:

 

Which microSD card size do you recommend and class do you recommend... do you have a preferred brand?

A board at my desk uses an SDC10/8GB Kingston microSD card, formatted as FAT32, which works fine. It's likely the equivalent of this one on our site: https://digilent.com/shop/microsd-card-with-adapter/.

9 hours ago, Oscar O. said:

You said: "you can check the linker script (lscript.ld) to confirm."  Are the lines below the ones that define the buffer area?

All sections of program memory are placed in DDR. The LWIP sources should be using malloc under the hood, which allocates memory in heap. A related question was answered here: https://support.xilinx.com/s/question/0D52E00006iHli2SAC/raw-lwip-memory-management-zynq?language=en_US.

9 hours ago, Oscar O. said:

 

So when the Vitis project is compiled it understands the hardware it is dealing with and sees that there is a DDR3 memory it can use to store information... is that a accurate description?

Yes. The linker script defines what parts of the compiled project get placed at what addresses.

9 hours ago, Oscar O. said:

Going back to the audio project, I see that the block that interfaces with the external codec (d_axi_i2s_autidio) hooks up to the DMA block using the axi..the axi_interconnect block then is hooked up to the ZynQ7 via the S_axi_HP0 port. How does the dma know where the microphone sound buffer resides in the DDR3 memory (location)? Is this a parameter that gets programmed to it?? Just trying to see how it all fits together. Sorry for all of the questions I have never done a project with Zynq processor and Vitis.

The AXI DMA has a register that the processor writes in order to specify the buffer's memory address. Using the xaxidma API, this is done through a call to XAxiDma_SimpleTransfer. The same call also sets the length of the memory buffer so that the hardware knows when it might overflow the buffer and corrupt things if it continues writing. See here: https://github.com/Digilent/Zybo-Z7-SW/blob/c21218c91e7d6dfd2018d35932a5f0d9d38eec9a/src/Zybo-Z7-20-DMA/src/audio/audio.c#L383 - the function call specifies that the DMA should transfer into a buffer located at MEM_BASE_ADDR, which is five times the number of samples bytes long.

[Oscar O.]

Hi Arthur, 

  I think I found a udp echo file I can use but wanted to make sure the normal tcp echo server project would work. Before doing so I called our IT support and they told me I could use the second port of my laptop to test with the board as long as I disconnect the other ethernet port from the company's network. I did that and proceeded to change the PC's ethernet address  as instructed in the echo project to: (192.168.1.200, mask 255.255.255.0) since I am hooking up to the PC directly instead of through a router.

I then build and ran the project, it came up but along the way gave a line that says DHCP timed out... see below. Nevertheless I went ahead and opened a putty window and tried to telnet to 192.168.1.10 and it would not do it, I got a message that said that it could not be reached. I even opened a command window and did ping 192.168.1.10 to no avail. 

Any thoughts why I cant reach it?

 

[artvvb]

If you have multiple ethernet connectors on your computer, you might try each of them, updating an IP through the network and sharing center, like in step 11 here https://digilent.com/reference/programmable-logic/guides/zynq-servers#testing_the_server_without_a_dhcp_router, corresponds to one of them rather than all.

The DHCP timeout is expected - there's no router there to handle DHCP. Based on the mention of RTL8211F in the printouts, did you update xemacpsif_physpeed as described in the prereqs section? https://digilent.com/reference/programmable-logic/guides/zynq-servers#update_ethernet_support_boards_with_rtl8211f_chip. I'm not sure what happens when the fix isn't installed, but will check with a colleague.

[Oscar O.]

I was able to find an echo.c which does UDP and used ncat --udp 192.168.1.10 7 to test it.... it does echo back. I found a youtube video of a dma loopback (data to axi_fifo and back). So I added the appropiate blocks on the .bd schematic and the code they had written on the main.c on top of the code that was there from the echo project. It is giving me an error saying this when I go build it: ../src/main.c:36:10: fatal error: xaxidma.h: No such file or directory. Not sure how to get around this. I did export a new .xsa file from Vivado.

When I export the .xsa file it is in the directory where the .xpr file is for Vivado. But looking at the property of the .xsa file in the vitis environment it is down projext.sw/design_1_wrapper\export\design_1_wrapper\hw\design_1_wrapper.xsa so wondering if that is the problem (it does not see the new dma block in the schematic).

You would think Vitis would see that it changed and copy??? it to the correct directory. Nevertheless I copied the .xsa to that directory and it still gave me an erorr.

I am hoping to get the dma lookback working along side the UDP loopback.

Then modify things so I send via DMA the udp buffer p to the axi fifo on the PL side.

Finally remove the path out of fifo back to dma module and have my logic in the PL read the fifo once the data is there so I can send it out serially (cant use an axi_uart since it is straight data and clk....clk on data is being sent out (no  start bit etc) ).

Here is the new schematic

 

Edited April 18 by Oscar O.

[artvvb]

1 hour ago, Oscar O. said:

When I export the .xsa file it is in the directory where the .xpr file is for Vivado. But looking at the property of the .xsa file in the vitis environment it is down projext.sw/design_1_wrapper\export\design_1_wrapper\hw\design_1_wrapper.xsa so wondering if that is the problem (it does not see the new dma block in the schematic).

You would think Vitis would see that it changed and copy??? it to the correct directory. Nevertheless I copied the .xsa to that directory and it still gave me an erorr.

You should manually update the hardware specification: https://digilent.com/reference/programmable-logic/guides/vitis-update-hardware-specification. Vitis generally won't see changes to the filesystem. When just overwriting the copy of the file buried in the platform project, I'd be concerned that Vitis might need to extract other files from it, which it might not happen automatically during a build - I expect it won't see the copy without the manual update.

One common issue that could come up after this (though I don't think you'll run into it here) is that if your XSA file has a different name, the extracted bitstream name changes. In this case, you'd need to go into the system projects Run/Debug Configurations, and change the path to the file to reflect the name of the new XSA.

[Oscar O.]

Manually updating did the trick... thanks.