UPGRADE YOUR BROWSER

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!

Adam Taylor’s MicroZed Chronicles Part 101: Accelerated Bare-Metal Programming with SDSoC

by Xilinx Employee ‎09-21-2015 09:49 AM - edited ‎01-06-2016 12:45 PM (35,662 Views)

 

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:

 

 

Image1.jpg

 

 

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:

 

 

Image2.jpg

 

 

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:

 

 

Image3.jpg

 

 

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.

 

 

MicroZed Chronicles hardcopy.jpg

 

 

 

 

  • Second Year E Book here
  • Second Year Hardback here

 

 

 

 MicroZed Chronicles Second Year.jpg

 

 

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

 

Comments
by Observer jamey.hicks
on ‎05-24-2017 12:00 PM

Do you know where the 8088 cycles of overhead comes from?

by Observer taylo_ap
on ‎05-27-2017 02:43 AM

Jamey 

 

I think it is becasue Linux is a more more detailed and complex OS. With baremetal and free RTOS when the accelerated function in the PL has completed its task, it can issue an interrtupt for service. As both baremetal and free RTOS are not running many if any additional tasks they can service the interrupt very fast. Linux by comparision has to complete the tasks it is running before it can call the ISR. 

 

This could be a good example for trying the tracing on the see exactly how the timing breaks down see blog 154 for details on that 

 

Adam 

Labels
About the Author
  • Be sure to join the Xilinx LinkedIn group to get an update for every new Xcell Daily post! ******************** Steve Leibson is the Director of Strategic Marketing and Business Planning at Xilinx. He started as a system design engineer at HP in the early days of desktop computing, then switched to EDA at Cadnetix, and subsequently became a technical editor for EDN Magazine. He's served as Editor in Chief of EDN Magazine, Embedded Developers Journal, and Microprocessor Report. He has extensive experience in computing, microprocessors, microcontrollers, embedded systems design, design IP, EDA, and programmable logic.