Zybo Zynq-7000 Ethernet and UART Connection

[Adaline]

Hello, would it be possible for the Zybo Zynq-7000 to receive a signal via Ethernet and transmit it via the UART/USB port?

My understanding of is that since Ethernet and the UART can be on the PS, there is a possibility of connecting these ports here by using software written in the SDK. If this is true, how would one go about this? Are there any functions I could look into?

Another option would be to connect them in the PL, as Ethernet can access the PL via EMIO interface GMII, and UART signals can be routed through the EMIO. This would require a (probably?) non-trivial Verilog block in the PL to convert UART to Ethernet, which isn't preferred for me as a beginner in Verilog (or HDLs in general). If the above software-based solution isn't possible, how would you approach this design, and how feasible is it?

[zygot]

11 hours ago, Adaline said:

would it be possible for the Zybo Zynq-7000 to receive a signal via Ethernet and transmit it via the UART/USB port?

The simplistic answer is, of course. It's just a software effort.

A more complete answer follows:

PS UARTs aren't great and have very shallow RxD and TxD FIFOs. There are example projects to help get started.  A bigger problem is that the Ethernet and UART interfaces have very different data rates( 125 MiB/s for 1 GbE; less than 100 KiB/s for a UART operating at 921600 baud with no flow control ). Ethernet data transport is packet oriented, UART is not. Ethernet works with binary data; UARTs are designed for ascii text data ( though it's possible to do binary ). There are a lot of differences to resolve.

ZYNQ Ethernet using the GEM requires DMA, and this is complicated using the Standalone Xilinx OS libraries. Still, there are examples to read through. What you want to do is fairly complicated, even for someone with experience using ZYNQ devices and the tools. You mention the SDK. This was depreciated in favor of the more integrated Vitis software development tools since Vivado 2019.2.

Can you provide a bit more details about what, exactly you want to do?

Ethernet PHYs and UARTs connected to PS pins can't be connected to the PL via the EMIO. Ethernet PHYs and UARTs can be connected to unused PS GEM and UART modules vis the EMIO if they are connected to PL pins. Ethernet via EMIO is restricted to a GMII interface.

In general, ZYNQ is designed to use DMA to move data between the PS and PL, or PS connected external memory and PL using AXI bus resources. Vivado has some free IP to do that, though it in't always very robust. AXI interfaces are beyond the capability of most people just starting out learning the HDL development flow.

ZYNQ development can make even simple designs more complicated and time consuming than it might be in an FPGA without the ARM processors.

Edited April 8, 2023 by zygot

[Adaline]

3 hours ago, zygot said:

The simplistic answer is, of course. It's just a software effort.

A more complete answer follows:

PS UARTs aren't great and have very shallow RxD and TxD FIFOs. There are example projects to help get started.  A bigger problem is that the Ethernet and UART interfaces have very different data rates( 125 MiB/s for 1 GbE; less than 100 KiB/s for a UART operating at 921600 baud with no flow control ). Ethernet data transport is packet oriented, UART is not. Ethernet works with binary data; UARTs are designed for ascii text data ( though it's possible to do binary ). There are a lot of differences to resolve.

ZYNQ Ethernet using the GEM requires DMA, and this is complicated using the Standalone Xilinx OS libraries. Still, there are examples to read through. What you want to do is fairly complicated, even for someone with experience using ZYNQ devices and the tools. You mention the SDK. This was depreciated in favor of the more integrated Vitis software development tools since Vivado 2019.2.

Can you provide a bit more details about what, exactly you want to do?

Ethernet PHYs and UARTs connected to PS pins can't be connected to the PL via the EMIO. Ethernet PHYs and UARTs can be connected to unused PS GEM and UART modules vis the EMIO if they are connected to PL pins. Ethernet via EMIO is restricted to a GMII interface.

In general, ZYNQ is designed to use DMA to move data between the PS and PL, or PS connected external memory and PL using AXI bus resources. Vivado has some free IP to do that, though it in't always very robust. AXI interfaces are beyond the capability of most people just starting out learning the HDL development flow.

ZYNQ development can make even simple designs more complicated and time consuming than it might be in an FPGA without the ARM processors.

Thank you for the detailed answer Zygot. It seems there’s a lot of work cut out for me and my team.

The bigger picture view of our project is that we’d like to route packets to and from different PHY interfaces on the Zybo (Ethernet is on board, WiFi, Bluetooth, and Zigbee are on PMOD) to a computer (likely communicating by USB/UART to my understanding, but this could change). The computer would then run some packet analysis protocol, which another teammate is working on.
 

As someone working on the “FPGA side” of the project, I’m trying to find a way to get data from different PHY inputs (Ethernet, WiFi, Bluetooth, Zigbee) through the Zybo to the processing computer. Any assistance would be greatly appreciated.

Edited April 8, 2023 by Adaline

[zygot]

Sounds like a very interesting, but very, very, ambitious project. ( did I mention VERY ambitious? )

I'd suggest spending a few hours working out the basic details before jumping in and starting a design. If you want to do this in real time, you have a pretty complicated project to design and implement and write software for. Figure out the relative data rates for all of your interfaces, and required storage. You're likely going to have to limit incoming packet types and rates to make the design manageable. Work out how much storage will be required. We've already talked about the relative data rates of Ethernet and a UART.
Using a PC UART to pass binary data might be tricky, though it's certainly possible for a USB UART device and the correct library API.

You'll want to analyze the project requirements and plan an approach carefully or this project will blow out of control. Do you understand all of the packet types for all of the standards that you've mentioned? Can your FPGA platform and your chosen PC interface handle the raw data rates? Is a PC really where you want to do the analysis? I can't provide answers to these questions, but I can assure you that you don't want to be learning the details well after you are into development.

In the beginning you might want to break up chores. One person could try and prototype basic FPGA HW/SW just to see what you are getting yourselves into. Another person might run the data rate analysis and come up with storage requirement estimates and a basic software design approach. Interrupts, especially for multiple interfaces can get pretty complicated on a ZYNQ using the tools.

If this is a senior project you might consider narrowing and refining the scope of the project goals considerably. You can away go bigger if time allows....

Selecting the slowest interface as a data pipe between your FPGA platform and where you want to do your packet analysis strikes me as a sign that your team hasn't thought out the details very well yet. Just my personal observation. Edited April 8, 2023 by zygot

[D@n]

If this is a software project, it's pretty easy.  I wrote this in an afternoon.  It does almost exactly what you are looking for (though it splits data across two TCP/IP network streams), and it'd be fairly easy to adjust back to a single stream again if you wished to.  (You might even be able to find the single-stream version in the git history, for exactly what you've described.)

If this is an RTL project, then yeah, it'd be a bit more ambitious.  The key question here, though, is where is the hardware/software boundary?

Dan

[zygot]

@D@n,

Nice to hear from you again.

I'm guessing that if you ported this to the ZYBO, it'll take you more than on afternoon's effort. But if you ignore hardware considerations, yes conceptually, the basic idea might be reasonably straight-forward.

In my experience, when teams of people are working on conceptualizing a framework for solving a problem, and historically, the teams are divided into software and hardware ( in some places logic design is software ) then there can be wildly differing ideas on how the problem will be implemented ( and integrated, and fixed ).

So, Dan., tonight your task is to execute your simple code on a Raspberry Pi, or a ZYBO, ( you've no doubt done this on an ARTY-35T ) and let me know how it all worked out. Oh, and don't forget that you are going to do packet analysis on a PC. Just sayin': the difference between trivial and impossible is in the details....

Aren't senior project wonderful?

[D@n]

That particular software was rebuilt for a Pi years ago.  As I recall, the rebuild didn't require changes--it just needed to be recompiled with the ARM compiler.  The software works in a Linux system environment, and the network and UART interfaces are all well defined there and have been for years.

As for senior projects, there's quite the challenge on the instructor's side that I've seen over the years, and that is estimating the complexity of the project.  Often instructor's have no real clue what the students are up to and so wildly over or under estimate the student work load.  I suppose it just goes with the territory.  It's just something I've often seen, and so something I'm sympathetic to when reading of these things.  In this case, the project can go from nearly impossible to trivial depending upon details the student hasn't (yet) shared with us.