By Adam Taylor

When we last looked at creating our own SDSoC platform, we’d created a platform, built a simple software program, and checked that the Zynq SoC’s XADC was present as expected in the resultant utilization report. We did not attempt to accelerate any functions using the Zynq SoC’s PL (programmable logic) and we did not try to use the XADC within a software application. We will now that our platform is capable of doing both in this blog post by combining the previous AES encryption example with the XADC platform.

My aim is to read from the XADC, encrypt the XADC data using the AES function, and then accelerate the AES function in the PL. As this is a pipe-cleaning example, we will only encrypt 16 samples from the XADC and we will scale the 12-bit XADC value to 8 bits for the AES encryption.

First, we must map in the correct driver files to drive the XADC within the hardware; this is very simple. We use SDSoC as we would for a normal SDK application and create a hardware platform using the HDF file within the <project_name>.sdk folder. Then we create a new BSP using that hardware platform (see blog 2; the process is the same for SDSoC). This step provides us with a driver header file for the XADC. We’ll need to use the xsysmon.h file and we’ll also use the xparameters.h file generated by this step.

The reason we need to do all of this is to create a BSP. Until we build SDSoC, there is no BSP available. Unless we include these header files for the drivers, we will not be able to compile the software correctly.

Once we have created these files, we need to ensure that SDSoC can see them. There are a number of ways we can do this:

As there are only a few files in this example, we can add them to the SDSoC source directory We can update the <project>_sw.pfm definition with the location of the new include files and the BSP MSS file We can add in a new include file location via the project properties

Option 2 is the preferred option and is very simple to do. We just create a directory under our new definition and copy in the header files from the newly created BSP. Then we update the software PFM file as below to define the BSP configuration and the location of the new header files:

The next step is to ensure that we can accelerate the AES function. Previously, I wrote the software that I wanted to pipe-clean this stage. (You can probably tell that my day job involves developing systems for space.) When I first attempted to do this, I very quickly ran into an error because I had previously created the hardware platform (see blog 108) and I had only included the private processor interrupt needed for the XADC. What I had not done was think ahead to SDSoC’s needs.

Obviously, to create efficient solutions, SDSoC requires the use of the Zynq PL-to-PS (programmable logic to processor system) interrupts for data transfer etc. As such, I had to go back and recreate the platform with the Shared Peripheral Interrupts from the PL to the PS enabled.

To correctly use these in SDSoC we need to connect a concatenation block as below connected to the interrupts:

Note: Ignore the critical warning on the floating input to the concatenation block when you validate and generate the output products.

With all of these tasks completed, I could finally create an application to take the XADC data and encrypt it using AES. When I ran this program using just the Zynq PS running a bare metal system, the software task consumed 28350 clock cycles—similar to that we achieved previously (blog 102).

Setting the AES encryption to run within the Zynq SoC’s PL side reduces the execution time to 12467 clock cycles, which is slower than the previous example because I only provided a 100MHz clock for use in the PL with the SDSoC hardware platform. This result teaches us another lesson about generating your own hardware: make sure you have included all of the clocks possible at frequencies you have considered.

We can now use the Zynq XADC within SDSoC and we can accelerate things using the Zynq SoC’s PL side. Now that we have a new SDSoC Platform, we can finally begin to look at signal processing.

Next time.

If you want E book or hardback versions of previous MicroZed chronicle blogs, you can get them below.

First Year E Book here

First Year Hardback here

Second Year E Book here

Second Year Hardback here

You also can find links to all the previous MicroZed Chronicles blogs on my own Web site, here.