Showing results for 
Show  only  | Search instead for 
Did you mean: 

Creating an Acceleration Platform for Vitis Part Four: Testing a Custom Acceleration Platform in Vitis

2 2 2,528

In the previous blog entries in this series we discussed how to create the hardware and software project. We then discussed how to package this project in Vitis™.

Next, we will be testing it in Vitis, by created a simple application that will be accelerated.

This is part four of the guide. You can find the other parts at the links below:

Part One: Creating the hardware project for the Acceleration Platform in Vivado

Part Two:  Creating the software project for the Acceleration Platform in PetaLinux 

Part Three: Packaging the Accelerated Platform in Vitis 

Creating the Application:

Launch Vitis, and Create the Application Project.

Select a platform from the repository, and click the + icon:


Browse to your custom platform:


Note: Make sure that the flow is set to Embedded Accel.

We can also see some resources. These are the clocks that we enabled.

Give you project a name:


The application settings should be auto-populated using the settings you entered when packaging your platform:


Lets use the template here:



If users do not have access to Hardware, then they can use emulation to test. We can use the Quick Emulation (QEMU) tool to emulate the system using pre-built DTB files (not to be confused with the dtb used for in the Linux image from PetaLinux).

There are two emulation build types; Emulation-SW, and Emulation-HW. 

Emulation-SW will emulate the whole system. However, to fully evaluate the RTL logic generated by the tool, Emulation-HW should be used. This uses a co-simulation between the QEMU and the XSIM. Note: QEMU is not cyclic accurate. Therefore, the memory model will not be cyclic accurate. As a result, performance numbers given by the Emulator should be used only as guidance. 

For example, to use the Emulation-SW:


Then Build:


Then right click on the app, and select Run As and Launch on Emulator:


You will see the Linux boot in QEMU in the Emulation console, and then hopefully you will see the test pass in the console window:


Test on Hardware:

I am planning to run this on my ZCU104 board, so I have changed the Active Build Config to Hardware:


Then Build:


So, what just happened here? Well, a lot actually:

  • Vitis used HLS to convert the C code to RTL, and packaged this with an AXI interface
  • Vitis then called Vivado and re-opened your XSA file, then added this new IP core
  • Vitis then used the metadata in your PFM to connect this IP core to the CPU
  • Vivado then re-implemented to create an updated bitstream
  • Vitis then re-packaged this bitstream in the boot image
  • The Vitis linker created the container file XCLBIN. The XRT parses this file to get the hardware and platform data needed for the kernels
  • The Vitis compiler generated the application file that will execute the kernels
  • Finally Vitis created an SD card IMG

Now format the SD card with the sd_card.img. file.

I used win32 disc imager:


Your SD Card should now look like the following example:


If you do not want to use the imager, then copying manually will suffice.

Running the Application:

Boot the Linux image, and use the commands below:

cd /mnt/mmcblkp0
source ./
./my_first_accel binary_container_1.xclbin


And that's it. we have now successfully tested the application.


Very helpful serial. Thank you for such a detailed tutorial. I followed all 4 episodes. And all step works fine. 

At first try, I changed the petalinux configuration of the ethernet  to static IP instead of DHCP which causes Vitis failed to connect the default TCF agent of the emulator. Then I changed it back to DHCP and all works well.

There is one question in me about Part 3 and Part4 where assign the image.ub as Kernel image and rootfs.cpio.gz as Root FS both in platform project and system project. The file image.ub should already contain kernel image, DTB and ramdisk in it so I think the file rootfs.cpio.gz here will have no influence in the result. The system will also boot normally (even assign another file to replace rootfs.cpio.gz) because according to  Xilinx wiki Using Distro Boot With Xilinx U-Boot,  and the recipe file  meta-xilinx/...../ and meta-user/..../u-boot-zynq-scr.bbappend which generate boot.scr, if there is a image.ub in the boot partition, u-boot will use only image.ub to boot. Other DTB and rootfs related files will be ignored.



Im glad you liked the blogs.

"The file image.ub should already contain kernel image, DTB and ramdisk in it so I think the file rootfs.cpio.gz here will have no influence in the result"

We are point to the path that contains the Linux image. This can be the image.ub, or the Image kernel. In 2020.1, the DTB is loaded via the BOOT.BIN file. u-boot loads this as shown here:

Also, are you noted, we are using the boot.scr. So, if you have a image.ub, this will be used via bootm. However, you can use booti too if you have an Image + rootfs