By Adam Taylor

We’re starting the third year of this series. Over the next few blogs, I plant to redo the same AES example we’ve been exploring with Linux using both Free RTOS and the bare-metal SDSoC option. This will ensure that no matter which of the operating systems we use for our application, we will have the topic covered.

As engineers, it is our responsibility to select the correct operating system for the application when we define a system’s architecture. Each project will have different requirements including response times (is an RTOS required?), networking support, file systems etc. We must also remember that for many of these applications, we want to be first to market—so heritage and experience also count.

I am going to start by looking at bare-metal systems. As such, we first need to create a new SDSoC project. We select the standalone option for the OS as shown below:

I copied the same files as for the previous AES example into the source directory of the new project.

With the files stored in the project, the next step is to build the project to run on just one ARM Cortex-A9 core in the Zynq SoC’s PS (processor system). The main reason for doing this is to measure the execution time of the bare-metal version of the algorithm. By definition, there is no operating system on a bare metal system so there is no scheduling or context switching. These tasks impact the performance.

Here’s the result of this experiment:

Running the bare-metal AES algorithm on the Zynq SoC’s PS side takes only 28574 clock cycles compared to the 36662 clock cycles when the same code was executed in the Zynq SoC’s PS running Linux, so Linux adds an overhead of 8088 clock cycles in this example. Remember however, there are many reasons for selecting one OS over another. Execution time will be one of many criteria.

With the bare-metal baseline established, I then told SDSoC to accelerate the AES function using the Zynq SoC’s PL and selected the same parameters I did previously:

Data Motion Network Clock Frequency 200 MHz

Clock frequency 166.67 MHz

The results of accelerating the AES encryption using the Zynq SoC’s PL:

For the Linux version, the result was 16544 clock cycles. We can see that PL acceleration improves performance in the bare-metal example by 75%. The improvement for the Linux version was 55%. But again, we must take into account the simpler software architecture of the bare metal system as opposed to Linux. Bare-metal code is faster because it does less.

Indeed, if we were to add in the 8088 clock cycles difference between the Linux and bare-metal PS execution back into the bare-metal result, treating Linux execution as overhead, we would find that the execution time of the accelerated function is about 54% faster than the bare-metal code running on the Zynq SoC’s PS. That’s very close to the Linux accelerated performance result.

Bare-metal code is one of the three OS options directly provided by SDSoC. The third is Free RTOS, which we will look at next. Once we have looked at the Free RTOS example using SDSoC, we will look at how we can use other operating systems such as Micrium OSiii within the SDSoC environment.

It will be interesting to see the performance results for the same AES example when we use Free RTOS next week.

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.