ZUBoard 1CG Development Kit RoadTest

Table of contents

RoadTest: Sign Up to Review the Avnet ZUBoard 1CG Development Kit

Author: folliard

Creation date:

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: Intel/Altera is the closest I can think of but has a steeper learning curve in my opinion.

What were the biggest problems encountered?: Getting software installed into a conda virtual environment came with a host of problems. Some were overcome and I hope this will help others. The first problem was finding a conda that actually worked with the aarch64 instruction set. The work I sought to reproduce on the board was originally written in Python 2.7 for the x86_64 architecture. Finding required software packages and libraries compatible with both Python 2.7 and the aarch64 architecture was the biggest problem encountered.

Detailed Review:


The package arrived on a Monday via UPS.  Inside were three boxes securely packaged inside a plain brown shipping carton.


  • Zuboard 1CG
  • Camera module (not used)
  • A beefy 3 A USBc power adapter
  • A nice Anker USBc cable
  • An 8 GB SD card (also not used)

Hardware Overview

Zuboard 1CG

  • Dual-core ARM Cortex A53 MPCore
  • Dual-core ARM Cortex-R5F MPCore
  • 81,900 logic cells of AMD Zynq UltraScale+ FPGA fabric
  • 1 GB ISSI LPDDR4 memory
  • 256 MB ISSI QSPI flash memory and microSD non-volatile boot options
  • USB 2.0 controller, 100/1000 Ethernet and JTAG via microUSB

DualCam camera module

  • The camera was not used

Power adapter

  • Capable of 15 V and 3 A
  • Power on LED indicator

Power cable

  • A nice, braided Anker USBc cable
  • Approx 6 ft length

microSD card

  • 8 GB Delkin Devices Utility+ microSD card.
  • UHS 1 rating (10 MB/s minimum sequential write speed)

Additional Hardware required for roadtest

Laptop computer

  • USB to communicate with Zuboard

USBc dongle

  • USB and Ethernet for interfacing with Zuboard
  • SD card slot

Larger microSD card and adapter

  • 64 GB SanDisk Extreme PLUS
  • V30 rating (30 MB/s minimum sequential write speed)
  • Adapter to plug into dongle

Laptop computer configuration


  • macOS Big Sur 11.7.1
  • 2.3 GHz 8-Core Intel Core i9 with Hyper-Threading
  • 64 GB 2667 MHz DDR4
  • 2 TB M.2 SSD (approx 1.48 TB available after installing Vitis HDL in guest)
  • Parallels Desktop 18 Business edition 18.3.2


  • Ubuntu 22.04.2 LTS
  • Up to 8 processors
  • Up to 32 GB memory

Hardware test

The ZUBoard comes preloaded with a test program in the onboard QSPI flash memory.  After connecting to the JTAG/UART debugging port with microUSB to the USBc dongle to my laptop and making it available to my virtual machine, I connected the supplied USBc cable to the power adapter and the power indicator LEDs lit up.  I found it easiest to connect the ZUBoard directly to my home network so it would be assigned an IP address by DHCP and routable from other computers in the house.  I ran sudo screen /dev/ttyUSB1 115200 in the terminal.  When I pressed the power button (SW7), the board came to life.  POST messages rushed past on the terminal and, critically, I was able to see the IP address of the board.  Putting this into my web browser allowed me to access the embedded webserver on the board and run the test.  I especially enjoyed changing the colors of the LEDs.  Everything worked perfectly out of the box!

Software test

Being a Python fledgling and a complete newcomer to Vivado, Vitis and PetaLinux, the rest of this roadtest would not go so smoothly.  I will do my best to document each and every misstep in hopes that it may help someone like me in the future.

To roadtest the ZUBoard 1CG, I proposed using the board to train and test an ML model to identify the transmitter of traces recorded by an SDR.  The ZUBoard 1CG's arm processors and FPGA are a natural choice for such radio projects due to their prevalence in edge and IoT devices.

Specifically, I sought to get a GitHub project onto the board.  The project requires Python, conda, pip, as well as a number of additional packages and libraries to be installed and itself is comprised of Python 2 and bash scripts.  If I could get the project running on the ZUBoard 1CG I was also interested in leveraging the FGPA fabric for hardware acceleration.

Vitis and PetaLinux

I quickly discovered that PetaLinux is a Xilinx tool for deploying Linux to Xilinx SoC like the ZUBoard.  Furthermore, it was my understanding that Vitis would allow me to create hardware acceleration projects and that I could use this to create a PetaLinux image that would run on the board.  After being selected as a finalist for the roadtest, I began researching how to get the Vitis software on my laptop.

I reviewed system requirements for Vitis on the Xilinx website.  Seeing that macOS is not supported, I provisioned a new virtual machine in Parallels.  I saw the requirement for CentOS 7.9.  Since CentOS 7 has only been getting maintenance updates since 2020 and isn’t recommended for new development at this point, I decided to try version 9—do not do this!

I downloaded the Vitis installer from the Xinlinx website to my virtual machine.  I ran it with the command sudo ./Xilinx_Unified_2023.1_0507_1903_Lin64.bin.  I got an error right away that my operating system (CentOS 9) was not supported.  Furthermore, the list of supported operating systems as shown in the screenshot below indicated that CentOS was not supported for PetaLinux.  I do wish this was made more clear on the table of requirements on the website!  This would certainly not suit as I intended to use PetaLinux on the ZUBoard.  For these reasons, I decided to go with Ubuntu LTS.  After installing I realized I’d installed 22.04.2 instead of 22.04.1 but I did not get an error message when I went to install Vitis.


I tried several times to install Vitis.  Each time it would finish downloading and installing but hang at the same point just short of halfway through of the third Final Processing phase (see screenshot).  Not wanting to interrupt, I disabled the sleep functions on my laptop and virtual machine and left it to run overnight.  The next day, seeing no progress, I would shut down the virtual machine, increase the resources, and try again.  On the second attempt, I allocated four processors and 8 GB of memory.  On the third attempt I allocated eight processors and 16 GB of memory to my guest Ubuntu system.  Ostensibly, this attempt had also failed but when I restarted the virtual machine to try for a fourth time, the Vitis installer said it detected an installation of the software.  Installed or not, I am not sure that it is configured properly.


For one final attempt, I increased the memory for the virtual machine to the 32 GB and ran the installer again.  This also failed.  I was disappointed that all configurations tested up to and including 8 processors and 32 GB of memory for the virtual machine were insufficient for the Final Processing stage to finish.


As I was struggling with Vitis installation, I was also reading up on the PYNQ project.  PYNQ is an open-source project that brings Linux, Python, and Jupyter Notebooks to adaptive AMD hardware platforms including the ZUBoard.  Compared to Vivado and Vitis there are very few system requirements for my laptop or virtual machine to interface with the board as only a web browser is needed.  Preinstalled images were available for many adaptive SoC platforms, including the ZUBoard 1CG.  It is also possible to develop custom overlays and functions in Vivado or Vitis so it did not feel like a compromise to go this route.  The clear advantage was that I could directly write an image to a microSD card, boot Linux, and immediately start working on the ZUBoard itself.

I downloaded the image file from the PYNQ website and wrote it to a microSD card using Ubuntu Disks.  The image file is 9.8 GB so I did have to purchase a larger card which came with an adapter I used to connect it to the standard-size SD card slot on my dongle.  With the ZUBoard powered off, I changed the dip switch settings to select boot from SD.  After the image finished writing to the microSD card, I plugged it into the slot on the ZUBoard.  I connected to the serial port again by running sudo screen /dev/ttyUSB1 115200 in the terminal.  This time I was thrilled to see the familiar messages of a bootstrapping Linux system and in a few seconds I was asked to login.

Creating the Python/conda virtual environment

After logging into the board, I set to setting up the Python virtual environment.  Trying to install miniconda as suggested by the GitHub project failed so I tried anaconda.  Both failed with illegal instruction runtime errors and I read that they may have compatibility issues with the aarch64 architecture.  I suspect this may be due to an underlying compatibility issue with the aarch64 architecture despite the fact that I downloaded what were purported to be aarch64 installers of each.  It was at this point I started to realize that the GitHub project was going to be more difficult to get running on the ZUBoard than I’d initially thought.

After some further research, I discovered the miniforge project from GitHub.  The miniforge project is a minimal conda installation specifically targeting a variety of architectures including aarch64.  I downloaded the installer (wget https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-aarch64.sh) and installed it (bash Miniforge3-Linux-aarch64.sh).  

With conda installed, I set to create the virtual environment as specified in the GitHub project with the command conda create -n cxnn python=2.7 which seemed to take forever.  After a long time the system stopped responding entirely.  Over the course of a few attempts I noticed my ssh sessions would stop responding and I decided to watch the JTAG/UART interface using the screen command from my virtual machine as I tried to create the virtual environment yet again.  I observed memory usage was quite high and slowly even the swap was being filled up when finally the board completely locked up as it had before.  I realized there was only 512 MB of swap but I have plenty of space on my microSD card.  Since I had no way of increasing the 1 GB of onboard memory, I decided to increase the size of the swap file to 2 GB (twice the RAM) with the following commands.

sudo swapoff -a

sudo fallocate -l 2G /var/swap

sudo swapon /var/swap

sudo chmod 600 /var/swap

sudo swapon /var/swap

sudo reboot

After increasing swap, I pulled up htop over the serial port again and watched memory and swap usage as I again started the command to create the conda virtual environment.  This time, the operation finished.  I activated the new virtual environment with the command conda activate cxnn.  With the newly-created virtual environment active I was ready to continue installing packages and start training the ML model.

Installing packages and running training script

I downloaded the GitHub repository to the ZUBoard using the git clone command.  After downloading, I ran pip against a text file of required packages contained in the repo.  Most of these specified a version number.  As the project is now a little over three years old and written in Python 2.7, most of these package versions were no longer available or incompatible with the aarch64 architecture.

Due to it being a dependency for other packages, I focused one package in particular: scipy version 1.1.0.  I first tried using pip (pip install scipy==1.1.0), then conda (conda install scipy==1.1.0), and finally downloading a tarball of the source code and trying to install from that local source (pip install scipy-1.1.0.tar.gz).  I further downgraded pip to version 20.2 using the command pip install pip==20.2 as it was one of the last versions to support Python 2.7 and tried each method again.  Each time the package either failed to build, or not found in the conda channel.  When all these methods failed, I explicitly made sure all the dependencies were installed using the command sudo apt-get build-dep scipy and then installing using pip install scipy==1.1.0.  While the dependencies were all installed, scipy was once again found to be incompatible with the system.

Since so many software packages were not available in the versions indicated by the wireless-finerprinting project, or were otherwise not compatible with the aarch64 architecture, I decided to try Python 3.  I created and activated a new conda environment using defaults.

conda create -n cxnn3

conda activate cxnn3

In this Python 3 virtual environment I was able to get current versions of nearly all the packages installed without any difficulty.  I proceeded to run the training script from the wireless-fingerprinting project and was ultimately met with errors due to changes in functions and failed imports due to changes since Python 2.7 and the older versions of the packages.  I was able to overcome perhaps one of these errors, however, it now seems it will be far more work to port this project to the aarch64 architecture than I had originally anticipated. Specifically, the project calls for the mkl-service package which I have since learned is a library specifically made for Intel x86_64 math instructions.  I have not found any ports of this library so it would be necessary to replace any mkl-service library calls with calls to a different library.  It would also be prudent to rewrite in Python 3 due to the difficulty of getting a Python 2.7 environment working with all the required software packages.

Conclusion and next steps

While I was not able to get the GitHub project to run successfully on the ZUBoard 1CG, I feel I have learned a great deal about the ZUBoard and I am impressed with how easy it is to get a full blown Linux system installed and start developing right away on the target system.  In the course of the roadtest, I discovered a number of unknown unknown blindspots when it comes to Python.  Before this I have completed a few programming courses and an academic project using Python but I did not fully appreciate the challenges associated with trying to get a Python 2 project running in 2023.  I suspect this may have been easier to pull off on the original x86_64 architecture.  Now knowing that there can be more involved than just installing a different set of libraries, I have gained a far greater understanding and appreciation for porting software between different architectures.

The PYNQ project is a standout in my opinion.  I did not expect it to be as easy as writing an image to a microSD card and flipping a couple dip switches to boot a full operating system on the ZUBoard.  All the standard commands worked as expected and coming with Python and Jupyter notebook is a great bonus for a variety of projects.

I’m extremely grateful to have been selected for this roadtest.  The ZUBoard 1CG has proven itself easy to use and capable despite the challenges I faced in trying to get this particular project running on the aarch64 architecture.  I believe that this platform is a natural candidate for developing radio projects including rf fingerprinting.  WiFi access points and other radios rarely run on the x86_64 architecture but do often run on arm.  Bringing processing to the edge could allow for transmitters to be identified without transferring traces to a separate computer.  To be sustainable, I believe that the Python 2 scripts will have to be rewritten in Python 3 using current packages and platform-agnostic libraries.  I look forward to continuing this work as I gain proficiency in Python development.