Our MicroBlaze, Zynq and Zynq MPSoC solutions are increasingly software defined.

We use the application software running in the processor system (PS) to implement algorithms, manage data transfer within the device, implement communication links, and configure IP in the programmable logic dynamically.

This raises several challenges, as during development we need to:

Create custom software drivers and reuse them across projects (Xilinx SDK workspaces)

Create custom board support packages (BSP) and board definitions

Create new software libraries to be used across projects

Modify existing Xilinx drivers and libraries for the application

SDK repositories allow us to do all of the above, if we use them correctly.

We open the repository dialog by selecting:

Xilinx -> Repositories

Repository configuration

Within this dialog, there are three repositories, the installation repository, and global and local repositories.

While we cannot modify the installation repository, we can add new local and global repositories. However, before we add any new repositories, we should first understand the scope of these two repositories:

Local repositories are only available within the current SDK workspace

Global repositories are available across SDK workspaces

For example, we may use a local repository for changes we make to a Xilinx library or driver. Changes to it maybe important for the applications in the workspace for a particular solution, although we would not wish to apply the changes to every development.

If, however, we have custom drivers created for proprietary intellectual property (IP) or custom libraries we may wish to use these across several applications and hence workspaces. As such a global repository should be used, in fact the image above demonstrates this as it includes the location the Arm DesignStart Libraries on my system.

To work correctly, repositories are prioritized. This enables higher priority repositories to override identical components at a lower priority. In order of priority, the repositories are:

Local repository — highest priority

Global repository — medium priority

Installation repository — lowest priority

Let’s take a look a how we can use repositories if we need to make a change to a Xilinx driver provided with the BSP.

When we create a board support package for our Zynq / Zynq MPSoC design, one of the first things we do after we have imported the hardware definition is to create a board support package (BSP). This BSP contains a number of drivers which support the configuration of the hardware.

If we wish to examine the source code, we can look under the BSP libsrc directory. Under this directory we will see the source code for each of the drivers included in the BSP.

Library source code available for inspection

However if we make changes to these source files, for example to adjust a driver they are not included in the next build. Any changes are lost, this is because SDK is working with the compiled library Xillib.a which is created when the BSP is created or regenerated.

Compiled library

The correct way to create a modified driver is to use a copy of the driver in a repository.

To use a repository, the first thing we must do is create it and organize it correctly.

A correctly formatted repository contains the following folders:

BSP — used to hold software platforms and BSPs

sw_apps — used to hold applications

sw_services — used to hold libraries

drivers — used to hold drivers

To create a modification to a driver or library, we need to copy the original component from the Xilinx library into the correct repository directory (SW_Services or drivers). If you are wondering where to find the original driver on your system, the installation repository gives you the path.

Location of source drivers and libraries if modifications are necessary

For this example, I will only create a modified AXI IIC controller, by copying the AXI controller under my new repository driver folder.

Copied IIC driver for modification

Under the data directory, you will find the MDD file which contains the information on the driver. I opened this file using a text editor and changed the name from IIC to IIC_MOD — that way we will know our changes take effect.

Modified driver name

We are also free at this point to modify the source and header files as is necessary for the driver.

Once we are finished with our modification, we can then recreate the BSP source or create a new BSP, and the new modified driver will be available for use.

You can confirm this by looking at the drivers in the BSP settings.

Resultant BSP showing the modified driver

Modifying the drivers and libraries in this manner means that we still have the original source for other projects which do not require the change.

It is pretty rare that you need to make modifications, but occasionally there is a need to do so if you have device with unique properties or behaviors.

Now we know the best way to do this!

See My FPGA / SoC Projects: Adam Taylor on Hackster.io

Get the Code: ATaylorCEngFIET (Adam Taylor)

Access the MicroZed Chronicles Archives with over 270 articles on the Zynq / Zynq MpSoC updated weekly at MicroZed Chronicles.