Jump to content

Comunication speed increase between Eclypse z7 and PC


Riccardo

Recommended Posts

Hello

I have designed a custom acquisition system with the Eclypse z7 modifying the example with the ADC ZMOD1410 https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-scope

I managed to acquire a very large amount of data, which I want to transfer to the PC in some way. The  method used until now is the uart connection (used as in the example) but it is very poor in speed and in order to transfer the whole acquisition (917448 samples) it takes about 30min!

Is there any way in order to speed up the data transfer? I thought about ethernet connection but it seems very difficult to setup for me (I'm a beginner), in addiction I tried to settle up the echo server like in the following forum post but it did not work, as the image reported (Impossible to open a connection with the host n port 7: impossible to connect).

image.thumb.png.8bd904bc1f1ba5ffe5975ab2d1a45a5b.png

Does anyone have a suggestion or an example from where I can tap into?

 

Edited by Riccardo
Link to comment
Share on other sites

I recently posted this: https://forum.digilent.com/topic/24531-debugging-with-the-ftxxxx-mini-modules/

If nothing else, it might give you some ideas about how to boost that 921600 baud rate by 27x ( in terms of bytes/s data rates ). The Eclypse-Z7 PMOD design is unlike anything that Digilent has done so far. I haven't tried using the DBUG_CONTROLLER with the Eclypse-Z7, but had some ideas about a possible demo for that board. All you need is 4 pins of one of the PMODs to implement a similar concept. As it stands, my implementation is limited to blocks of 64 KB, but this isn't hard to get around.

The only alternative is the PS Ethernet. If you design has a data path to the PS, you can implement a simple Ethernet application using the PS GEM. As I recall, it's used by software tools for communications. The board also supports USB OTG, but you can't use the standalone software development path with the OTG stack. The truth is that you need to be using a Linux-like OS if you want the PS to use OTG or Ethernet in a user friendly mode. But Linux will have to run out of the limited PS DDR memory, along with the Etherent, the ARM cores, and any AXI DMA connecting the PS to the PL resources. All in all the Eclypse-Z7 platform is much harder to develop on than a good SYZYGY platform should be.  

So far no one has posted any questions to the thread in the link so I haven't had any incentive to update it.

Trying to use Ethernet with the standalone support is not trivial because of the way that the GEMs work. I think that Xilnx has just decided that anyone really interested in using ZYNQ PS Ethernet will be running on Linux, where open source code support is available. It's certainly the case for USB connectivity. Since ZYNQ is supposed to be ideal for cheap embedded applications, this strategy doesn't make a lot of sense to me; but it is cheaper for Xilinx.

Edited by zygot
Link to comment
Share on other sites

Thank you zygot for your reply.

I am actually using the Vitis serial terminal, which maximum baudrate I can choose is 115200, so maybe even only the 921600 baudrate you are referring can be faster, it the option for the baudrate in the SW code or is there any option to change in the platform.spr file of the hardware project?

I will also look at the ethernet application. Do you know any example I can follow?

 

Thank you for your time

Riccardo

Link to comment
Share on other sites

For some reason The SDK and Vitis serial consoles are limited to 115200; this may well be related to issues with how the tools use JTAG and platforms with FTDI JTAG/UART bridge devices. Personally, for the few ZYNQ projects that I do I don't use the PS UART to connect with a PC for debugging or data transfer. Actually, I seldom use the UART facility of Digilent boards in general for a variety of reasons. One big one is that I can use 921600 baud rates which are compatible with standard OS serial applications not using any flow control. I much prefer to use a couple of spare GPIO pins and a USB TTL UART cable or breakout board for that. I've had connectivity issues with the Digilent combination JTAG/UART interface on a number of boards, depending on what the UART is doing and especially when Xilinx tools are using the JTAG device. There's something about how Xilinx tools use the JTAG device that is problematic and that I haven't yet analyzed; it's just easier to side-step it. There are cheap 3.3V TTL UART cables and even cheaper USB UART breakout boards available from a variety of sources. A separate path is just better once you have HDL components or modules that work with UART communications.

As for ZYNQ Ethernet. There are LWIP example projects available for standalone software development that abstract away most of the very complicated DMA buffer low level tasks required for PS Ethernet connectivity. If you didn't add LWIP support to your current BSP you can always create a new BSP and just import one of the provided demo projects that interest you. The problem with that is that getting from a simplistic demo project where you can ping a static Ip address on the target ZYNQ platform from a PC to where you can transfer data between a PC and the target is not a simple matter. A lot of the SDK demos for connectivity interfaces require a hardware loopback arrangement to work. So, you need to carefully look at the source code provided in these pre-canned demos software projects, and read any Xilinx documentation, before diving in. Unfortunately, a cursory reading of what a lot of the demonstration code does can lead to frustration because they aren't designed to be functional end-use applications. I don't know of any open-source projects, using either Linux or standalone or RTOS software flows, for the Z000 family that demonstrates a complete PC Linux or Windows <--> ZYNQ Ethernet data transfer application that I;d want to use as a basis for a custom application.

It's unfortunate, but there are a lot of potholes and traps between the promise of ARM-FPGA devices and real world implementation... lot's of dead-ends depending on your design choices. For the most part one has to commit a lot of time and effort to discover them. Edited by zygot
Link to comment
Share on other sites

Thank you zygot, I think I will go on with the USB TTL UART cable suggestion: 
Can this (https://it.farnell.com/ftdi/ttl-232r-3v3/cable-usb-to-ttl-level-serial/dp/1329311?gclid=EAIaIQobChMIqODF3r3v_AIVxY1oCR3wEgQVEAQYASABEgJ-kfD_BwE&mckv=_dc|pcrid||plid||kword||match||slid||product|1329311|pgrid||ptaid|&CMP=KNC-GIT-GEN-SHOPPING-PMAX-NCA-Short-title-test-21-Dec-22&gross_price=true) be ok for the application? I can use two of the pins available form PMOD ports of the Eclypse z7 and use them as TXD and RXD and then connect the ground, is it right? Or is it better a solution with an actual board like this https://ftdichip.com/wp-content/uploads/2020/07/DS_FT4232H_Mini_Module.pdf ?

Link to comment
Share on other sites

USB UART Bridge devices generally support up to 3 Mbaud or up to 12 Mbaud. FTDI FTxxxxH devices support 8 or 12 Mbaud but not anything in between. So, this is the first decision to make. Is 921600 sufficient for your needs? For a lot of what I do with UART interfaces the answer is yes. In this case the cable that you mention from FTDI is am expensive but usable choice. I don't want to recommend any product, but I can tell you what I frequently use.

USB to TTL Serial Cable - Debug / Console Cable for Raspberry Pi from Adafruit. The nice thing about this is that it's cheap and has leads with female connectors that make it easy to connect to male header pins, or with cheap 1 row break-away male/male pin headers a PMOD.

FTDI Friend + extras - v1.0 from Adafruit.

SparkFun FTDI Basic Breakout - 3.3V from Sparkfun

There are other options from either vendor. Sometimes you need to use pins with 2.5V or lower TTL voltage levels and there are breakout boards that let you do that.

I find these indispensable for FPGA development and use them even with boards that have a UART connector.

If you want to do 8 or 12 Mbaud then you need to use something based on the FTxxxxH bridge device. An FTDI module based on the FT4232H similar chip is the best option that I know of. This path requires a bit more effort to set up and connect to your FPGA board. I use parts of custom PCBs that I've made for other projects to make this more mechanically secure. The nice thing about the effort that you have to put into this is that you can use what you've done with virtually any FPGA board with exposed .1" header GPIO pins. When your code is VHDL or Verilog you don't need any device or vendor specific source or simulation libraries.

It's a bit of a shame, but ZYNQ PS UARTs aren't capable of 12 Mbaud, but can do 10 Mbaud... which FTDI UARTs can't support. It's all about numerology. But you can connect one of the PS UARTs to the PL through the EMIO to external pins and use an FTDI module to let your ZYNQ PS talk at 10 Mbaud to a PC. The problem here is that the PS UART has very shallow UART data FIFOs. But you can address this in the PL using a BRAM as a FIFO.

If Digilent made PMODs with 10 signal pins ( 1 Vcc and one GND pin would do considering how much power their boards can supply to PMODs ) it would be possible to connect an FTDI FT232H or similar device and use the asynchronous 245 FIFO mode for 8 MiB/s data transfer. What a shame... Beware that moving up from USB UART type interfaces to USB 8-bit parallel data interfaces bring with it a slew of complexities and considerations to work out. I think that there are a lot of FPGA/PC applications where one or more USB UART 12 Mbaud channels are an ideal trade off between effort and usability.

[edit] I forgot to mention that you never want to connect a voltage source to most FPGA board headers when attaching external cables, modules and such. For the Adafruit cable I tape the Vcc wire to the cable to make sure that it's out of the way and never gets connected to on the the FPGA board IO, Vcc, or Gnd pins on a PMOD header.
 

Edited by zygot
Link to comment
Share on other sites

  • 2 weeks later...

Thank you zygot for your answer, I had a look around but did not have much time in last days to figure out a solution. 

Anyway I just realized that the board could have something that can help me without the use of external modules or cables: the USB Micro-AB device.

image.thumb.png.96f828caaffd8b24e4d1a8b44bb6f45a.png

Is this something easy to setup? I see that through the Block diagram in Vivado the USBIND_0 is already mapped into the right FPGA MIOs.

 image.png.fee242652571b0275a0c57797ee0311d.png 

If I want to use it, do I only need to use the functions in xusbps.h? 

image.png.7c51ff991d5ae7c50ac38953947cd7ec.png

Maybe the answer is "you just have to try it and don't bother us with silly questions". What I wanted to know is only if this idea could work or I do not have to take even in consideration.

Thank you very much

Riccardo

image.png

Link to comment
Share on other sites

You are correct that the ZYNQ can support USB 2.0 OTG if an external PHY is provided. The Eclypse-Z7 does this.

Now for the bad news. According to AMD/XIlinx Wiki documentation there is no support for OTG unless the PS is running a Linux OS and you are doing Linux software development. This means that you will have to use Petalinux and maybe Yocto to create your Linux system, FS, boot loaders, and make your HW visible to user space applications. It's a few orders of magnitude of increase in complications and complexity over standalone or even RTOS system design. But it can be done. Just getting all of the required tools installed to do anything significant is a challenge.

Xilinx support for changing HW (PL) applications on a ZYNQ system running a Linux build has been changing. You can read about the newest way to do this by looking at how Xilinx does it for Kria. There's a lot to get through....

I'd just suggest spending some time figuring out what you are getting into. Start here: https://xilinx-wiki.atlassian.net/wiki/home

I don't want to discourage you from taking on ZYNQ Linux development but it may be that the shortest path to getting to an acceptable place might be to learn how to use Ethernet in the standalone environment, if that's what you are use to working with.

I realize that the following observation isn't going to solve your Eclypse-Z7 problems, but sometimes a platform isn't the best one for an application. For anyone just wanting to capture a large amount of A/D samples and send them to a PC the USB104 or better yet the XEM7320 is a much simpler platform to work with. I know that Digilent advertises the Eclypse-Z7 as a "rapid Prototyping" ecosystem, it isn't even that for Digilent engineers much less their customers. Really, all you need to know, besides HDL development, is how to get data out of the converters into DDR and out of the DDR and into a USB interface... plus a bit of PC software effort using the vendors API or USB bridge API. It doesn't have to be any different than that.

A few months ago I made a 2 channel ADC capture and DAC playback build for a cheap Cyclone board. All HDL. Only VHDL and Verilog required. Simulation possible. Captures about .5 seconds of samples at an Fs of 125 MHz. It shouldn't be any harder than that, unless you are trying to sell something more expensive and less flexible. Edited by zygot
Link to comment
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
×
×
  • Create New...