MicroZed Chronicles: Vitis Emulation
How to use the different build flows available in Vitis.
Over the last few weeks, we have looked extensively at Vitis exploring:
- How to Create and Use Vitis in the Embedded Flow - Ultra96V2 Target
- Vitis Libraries for Acceleration
- Vitis High Level Synthesis
- How to Create a Virtual Linux Machine for Vitis Acceleration
- Creating a Vitis Acceleration Platform HW &SW - Ultra96V2 Target
- Deep Dive Into the OpenCL Example Application
- Creating a Vitis Acceleration Platform HW & SW for MicroZed
- Vitis Multi-Processor Environments - MicroBlaze and PS
In this blog, we are going to be looking at the different development flows that we can use when working with the acceleration flow.
These different flows are very useful when creating algorithms from scratch and we need to ensure not only functionality, but accelerated kernel performance as well.
In our previous examples, to demonstrate the created acceleration platforms have been implemented correctly, I used example applications and jumped straight to creating target hardware for the Ultra96 or MicroZed.
I could do this as we know the example application will work!
However, what approach do we take when we are developing our own algorithms and applications from scratch?
If we have to wait for the target application to build each time we wish to test our algorithm, it will significantly increase development time and limit our debugging capabilities. This is not what we want!
To enable us to develop algorithms and applications for acceleration, we have two additional options that we can use as part of the development flow:
- Software emulation: Runs both the host and the kernel on the x86.
- Hardware emulation: Runs the kernel as a compiled hardware model, while the host uses a C simulator.
Both the software and hardware flows are complementary and used at different stages of the algorithm design as shown below.
Software emulation is used during initial algorithm development and allows us to do the initial source level debugging required to detect functional issues and syntax errors.
As we are working in the x86 domain where the iteration time is very fast, we can also use traditional debugging techniques such as break points, etc.
Once we are happy with the function of the algorithm, we can progress to hardware emulation. This lets us optimize the performance of the kernel in the programmable logic.
To get started with the emulation flow, before we launch Vitis we need to run a few configuration scripts — these are the XRT, Vivado, and Vitis settings.
cd /opt/xilinx/xrt
source setup.sh
cd <install location>/Xilinx/Vitis/2019.2
source settings64.sh
cd <install location>/Xilinx/Vivado/2019.2
source settings64.sh
We can then start Vitis pointing to the workspace we desire to use.
vitis --workspace <wksp name>
Running both hardware and software emulation flows requires the correct configuration of QEMU in the acceleration platform. If you are unsure how to do this, check the QEMU User Guide.
If you did not include them the first time you created the platform, you can easily add them, and most importantly, re-build the project once you have added them.
With the QEMU information available, we are then free to select the build configuration from the dropdown menu in application project settings.
We can build the image just like before by clicking on the build button. You will notice both emulation flows are built much faster than the actual image.
As you select the build target and the build completed, you will see the Assistant window down on the lower left updating to show if that build is available.
Of course, once the selected build has completed, we want to try it out.
We can do this using the Assistant window by clicking on either the debug or run window and selecting launch on emulator.
Selecting this will enable you to start the emulator and run the example.
If we are doing hardware emulation, then we need to launch the emulator in GUI mode, otherwise the option will be grayed out.
Now all we need to be able to do is look at and analyze the data created by the emulator, especially in the hardware flow.
We will look at that next time!
See My FPGA / SoC Projects: Adam Taylor on Hackster.io
Get the Code: ATaylorCEngFIET (Adam Taylor)
Access the MicroZed Chronicles Archives with over 300 articles on the FPGA / Zynq / Zynq MpSoC updated weekly at MicroZed Chronicles.