We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 

MicroZed Chronicles: Getting Up and Running with Vitis

Xilinx Employee
Xilinx Employee
0 2 1,148

Editor’s Note: This content is republished from the MicroZed Chronicles, with permission from the author and Hackster.io.


How to create our first Vitis project.

After its announcement at last month's Xilinx Developer Forum in San Jose, Vitis was made publicly available with Xilinx's 2019.2 release.

First things first as the unified SW environment Vitis replaces SDSoC, SDAccel and even SDK.

As a unified tool, Vitis enables us to develop for embedded targets just as we did with SDK or application acceleration e.g. SDSoC and SDAccel.

Depending upon what we wish to do, there are different installation requirements.

  • Application acceleration requires a Linux OS and 64 GB of memory for Alveo applications, 32 GB for Zynq / Zynq MPSoC.
  • Embedded development requires either Linux or Windows and 32 GB of memory.

Both require about a 100GB of hard disk space.

When Vitis is installed, we also install the complete Vivado Design Suite, which saves us having to install them separately.


320_Fig1.jpgVitis installation

In this blog, I am going to look at the embedded development such that we can create an application in Vivado and port it to the Vitis to debug and run just as we have before.

Once we understand this flow, we will be able to build upon it and explore the acceleration flow.

The first change we will notice is what we export from Vivado; in previous versions we exported a hardware definition file. In reality, the HDF is a compressed file that contains the bit file and definitions and the PL and PS configuration.

320_Fig2.jpgHDF file viewed as an archive

Vivado now exports a Xilinx Shell Architecture, or XSA for short. We use this in Vitis to create a platform and in PetaLinux to create our embedded Linux solutions.

Exporting the XSA is very simple once we have completed our hardware design, as we can use the export hardware option. For this example, I am targeting an Ultra96 V2 with only the PS configured. There are no contents in the PL.

320_FIg3.jpgExporting the XSALike the HDF file, the XSA is also an archive file that contains the necessary information for the hardware configuration of the system.

320_Fig4.jpgXSA contents for a simple U96 design

Once the XSA has been exported, we can open Vitis from Vivado. We do this via the tools menu.

320_Fig5.jpgLaunching Vitis from Vivado

As Vitis launches, you will be asked to select a workspace for our VITIS developments.

320_Fig6.jpgSelecting Vitis workspace

Once the workspace has been selected, we will be presented with the IDE allowing us to create application projects or platform projects.

320_Fig7.jpgVitis Welcome page providing options for the developer

Here is where Vitis differs from SDK. Vitis splits the development flow into two elements a platform which contains the Hardware definition, BSPs and domains and the application.

320_Fig8.jpgVitis Relationships

This means that applications can be quickly and easily re-targeted to a different platform.

For this example we are going to create a simple baremetal platform for the Ultra96V2.

The first thing to do is select platform creation from the welcome screen and then follow the wizard.

320_Fig9.jpgStarting Platform Creation

We are then able to load in the XSA or use an existing platform. In this case we want to load in the XSA we just created in Vivado 2019.2, which will present you with the option below.

By default this will also generate the boot components for example PMU and FSBL for the MPSoC based designs.

320_Fig10.jpgSelecting the OS and Processor

This will the create a Vitis platform for the XSA we created, as you can see it will create the FSBL, PMU and BPS for the design. In this example with the Ultra96 we need to change the stdio from PS_UART_0 to PS_UART_1

You can change this using the modify BSP settings buttons, remember you will need to do it for the FSBL and PMU to if you want to see serial output.

320_Fig11.jpgHardware defintionOnce you have changed the BSP settings, if you want to explore the hardware definition you can click on the hardware specification tab on the bottom of the platform.

With a platform in place, we are now ready to create our first SW application. To do this, we can use the file new application option. This will create a new application and as we do not already have one a system project.

320_Fig12.jpgCreating a new application

A system project contains several applications which will run on the same platform simultaneously, e.g. applications running on separate A53 cores and the R5.

Once we have named the application, we get the opportunity to select the platform. You should see the Ultra96 V2 platform that we just created.

320_Fig13.jpgSelecting the platform

Once the platform is defined, we can also select the platform domain and our development language.

320_Fig14.jpgSelecting the domain

After selecting the domain, we are able to select a template application. I chose the Hello World application.

320_Fig15.jpgSelecting the Hello World example

Once this is created you will see both the application and the system project created.

320_Fig16.jpgSystem project settings

Under the system project, you will be able to see the application project intended to be run on APU core 0.

Once we have built this project, we are then able to download the ELF and execute it on our target Ultra96.

To do this, select the debug configuration options, this is similar to SDK, etc. and will present a list of potential debug configurations.

320_Fig17.jpgSelecting a debug configuration

For this example, while I could use the single application debug, I decided that it would be a good to show the system project debugger.

This gives us the ability to debug the entire system if we have multiple applications running. The only change I made from the default setting was to un check the use FSBL flow for initialization.

320_Fig18.jpgDebugging the application

Clicking on debug will then download the application. Open the debug perspective with the applications ready to run.

320_Fig19.jpgApplication downloaded and ready to run

Running the application will result in a nice and simple message being output over the terminal.


Of course, going forward Vitis is going to feature heavily in my blogs and projects and now we have a basic understanding of its embedded development flow.


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.

Visitor brandon.cerge

Great walkthrough. Im currently trying to get ahead of the learning curve for my group, but seems I am running into a slight issue. I have an Custom Artix7 Board, running a simple uBlaze core, when I try and create my custom platform, the OS and Processor just comes in blank, and Im at a hard stop... you might happen to have any ideas what my issue might be? 


Xilinx Employee
Xilinx Employee

Hi @brandon.cerge,

Thank you for reading the blog.

The author of this blog is happy to talk you through this offline. Please send an email to him (Adam@Adiuvoengineering.com). 

The following technical support options are also available to Xilinx customers:

  • Technical information is available online 24 hours a day from the Support website
  • Technical Support staff are available to respond to your questions in the Community Forums