Tag Archives: c

SDSoC Accelerate your AES Encryption



The Advanced Encryption Standard (AES) has become an increasingly popular cryptographic specification in many applications, including those within embedded systems. Since the National Institute of Standards and Technology (NIST) selected the speci- cation as a standard in 2002, developers of processor, microcontroller, FPGA and SoC applications have turned to AES to secure data entering, leaving and residing within their systems. The algorithm is described very efficiently at a higher abstraction level, as is used in traditional software development; but because of the operations involved, it is most efficiently implemented in an FPGA. Indeed, developers can even get some operations “for free” in the routing. For those reasons, AES is an excellent example of how developers can benefit from the Xilinx® SDSoC™ development environment by describing the algorithm in C and then accelerating the implementation in hardware. In this article we will do just that, first gaining familiarity with the AES algorithm and then implementing AES256 (256-bit key length) on the processing system (PS) side of a Xilinx Zynq®-7000 All Programmable SoC to establish a baseline of software performance before accelerating it in the onchip programmable logic (PL). To gain a thorough understanding of the benefits to be gained, we will perform the steps in all three operating systems the
SDSoC environment supports: Linux, FreeRTOS and BareMetal





Pretty much every embedded system / FPGA design has to interface to the real world through sensors or external interfaces. Some systems require large volumes of data to be moved around very quickly, in which case high-speed communications interfaces like PCI-X, Giga Bit Ethernet, USB, Fire/ SpaceWire, or those featuring multi-gigabit transceivers may be employed.

However, many embedded systems also need to interface to slower interfaces for sensors, memories and other peripherals these systems can employ one or more of the simpler communications protocols. The four simplest, and therefore most commonly used, protocols are as follows.

  • UART (Universal Asynchronous Receiver Transmitter): This comprises a number of standards defined by the Electronic Industry Association (EIA), the most popular being the RS-232, RS-422, and RS-485 interfaces. These standards are often used for inter-module communication (that is, the transfer of data and supervisory control between different modules forming the system) as opposed to between the FPGA and peripherals on the same board, although I am sure there are plenty of applications that do this also. These standards defined are a mixture of point-to-point and multi-drop buses.
  • SPI (Serial Peripheral Interface): This is a full-duplex, serial, four-wire interface that was originally developed by Motorola, but which has developed into a de facto standard. This standard is commonly used for intra-module communication (that is, transferring data between peripherals and the FPGA within the same system module). Often used for memory devices, analog-to-digital converters (ADCs), CODECs, and MultiMediaCard (MMC) and Secure Digital (SD) memory cards, the system architecture of this interface consists of a single master device and multiple slave devices.
  • I2C (Inter-Integrated Circuit): This is a multi-master, two-wire serial bus that was developed by Phillips in the early 1980s with a similar purpose as SPI. Due to the two-wire nature of this interface, communications are only possible in half-duplex mode.
  • Parallel: Perhaps the simplest method of transferring data between an FPGA and an on-board peripheral, this supports half-duplex communications between the master and the slave. Depending upon the width of data to be transferred, coupled with the addressable range, a parallel interface may be small and simple or large and complex.

The arty board provides four PMOD outputs (JA through JD) along with the Arduino / ChipKit shield connector through which we can interface with peripherals using these interfaces. Over the next few weeks I am going to interface the PModDA4 (SPI) and the PModAD2 (I2C) to the MicroBlaze System that we have created.

The first step is to generate the hardware build within Vivado such that we can interface to the PMODs. We can add in a AXI SPI controller from the IP library and configure it to be a standard SPI driver and not a dual or quad (more on those in future blogs). We can also add in the AXI IIC (remember to search for iic not i2c) controller module and connect it up to the AXI bus, do not forget to add both interrupts to the interrupt controller.



Once both controllers are within the design the next step is to customise for application at hand, with these complete we can assign the i2c and SPI pins to the correct external ports for the PMOD desired.

All that remains then is to build the hardware and write the software, it sounds so easy when we say it quickly.


Arty – FreeRTOS & XADC


Happy New Year! For the first blog of the year I thought we would combine the FreeRTOS and the XADC examples we had bbeen looking at previously.

This will enable me to show how we can do the following

  1. Configure the XADC
  2. Create a task to read from the XADC
  3. Create a second task to take action on the results from the first task

The intended functionality is the one task, once a second reads the XADC internal parameters and stores them within a array. This array is then communicated via a queue to the recieivng task which processes the results, for this example it just outputs them over the UART. If we wanted to this task could perform more detailed analysis or calcualtion on the results being provided to it.

We can easily modify the hello world example to perform this. If we wish to make it more complex and introduce more tasks which share resources, we must ensure they are properly managed and do not become deadlocked.

The first thing we need to do is include the proper header files such that we can use the API for the XADC we do this by including the “XSYSMON.H”.

Within the main function we are going to configure and initialise the XADC before we start the two tasks.

As we are going to be using the printf function and we are going to transfering data we need to ensure the stack size is correctly allocated. To prevent problems I decided to increase this to ensure there was sufficent for that requred for both tasks, when we create the tasks in the main() we are required to define the stack allocated to each task. For both tasks I decided to allocate 1000 bytes, I left the task pirorites as the receiving task being a higher priortiy than the transmitting task ensuring the data is transmitted as soon as it is received.


The next step was to create the queue, as I mentioned above due to the priorities of the RX and TX tasks there will only be one element in the queue, which will be the size of the size element XADC_Buf.

The final element is to start the scheduler and let the tasks run for ever well once we have written them.

We write each task as a we would any function in C, being careful to ensure we include the 1 second dealy within the transmitt task.

When I ran the code (which is available here) I got the following results.



Arty – XADC SW


With the hardware all built and the MicroBlaze system configured to support the XADC at the hardware level we need to be able to drive it at the software level.


The first thing you will notice is that having built the hardware in Vivado we need to open the implementation and export the design and the bit file to SDK. The next time we open SDK we will see a dialog box which states the Hardware platform we are using has changed and would we like to update import that to SDK and update the BSP, the answer of course is YES.

This will result in the hardware platform being updated and most importantly the BSP being updated to pull in the correct drivers for the XADC. We can see this if we open the BSP MSS file and click on customise the BSP button, this will open a dialog box upon which the drivers tab we can see the XADC and the driver used to control it in this case XSYSSMON.H. Looking around the BSP directory under the includes/libsrc/sysmon folder will show you the source code to drive the XADC.

Within our application SW how we initialise and set up a peripheral is very similar for all devices

  1. Define the peripheral of interest from the xparameters.h file in this case

#define xadc XPAR_SYSMON_0_DEVICE_ID

  1. Define the instance of the peripheral type we are going to be controlling

XSysMon xadc_inst;

  1. Declare a instance pointer to the peripheral type pointing to the address of the previous instance

XSysMon *xadc_inst_ptr =&xadc_inst;

  1. Declare a configuration pointer of the type of peripheral to be initialised in this case it is XSysMon_Config *xadc_config;
  2. Initialise the configuration pointer with the parameters for the peripheral in use in using the function

Xadc_config = XSysMon_LookupConfig(xadc);

  1. Initialise the peripheral using the function


With the initialization complete we can then proceed to configure the XADC as needed for our application To do this we use the drivers within the XSysMon.h these allow us to configure all of the ADC inputs, its sequencing and if it is interrupt driven or polled.

For this simple example I am going to configure the XADC to sample its internal parameters namely its temperature, VCCInt, VCCAux, VRefP, VRefN, VBram  as would be expected on a normal health monitoring system. This is simple to do using the functions below, this also disables all the alarms in the XADC.


                 XSysMon_SetAlarmEnables(xadc_inst_ptr, 0x00000000);




As I Mentioned in the last blog as we need to use the XADC to provide temperature information to the MIG we will also be enabling the temperature cycle update and defining the time duration this is updated at

XSysMon_SetTempWaitCycles(xadc_inst_ptr, 0x00000340);


The 0x340 relates to system clock cycles which are 83.25MHz to the refresh rate is 9.9939 us which is within the maximum refresh period of 10 microseconds.

Reading the XADC for this example is very simple I used a polled approach which checks for then of end of sequence bit before it asks for the XADC value.

                for(Index =0; Index <RX_BUFFER_SIZE; Index++){

                while ((XSysMon_GetStatus(xadc_inst_ptr) & XSM_SR_EOS_MASK) !=XSM_SR_EOS_MASK);

                                XADC_Buf[Index] = XSysMon_GetAdcData(xadc_inst_ptr, sample[Index]);


The final stage of the programme is to output the results into the table format as can be seen below over the RS232 link. IT is worth recording here that XADC returns a 16 bit result therefore to give the 12 bit accurate result the output result is shifted left by 4 places.


You can get the complete code here on the git hub

Over the next few blogs we will look at the XADC Interrupts and Alarms now we have a verified working platform.


Arty – Interrupts Part One


When we built the MicroBlaze system we included the ability to handle interrupts by the inclusion of an AXI Interrupt controller. This is connected to the interrupt input on the MicroBlaze controller each AXI interrupt controller is capable of supporting up to 32 interrupts. However, we can cascade the interrupt controllers to support up to 96 interrupts for each MicroBlaze instantiation.

Within the system we created in our first blog  , we had two interrupts one from the AXI UART lite and a second from the AXI Timer.


The interrupt signal from both the timer and UART are concatenated into a bus using the concatenate block as can be seen above. The intr input on the AXI interrupt shown above as intr[1:0] will scale automatically depending upon the size of the buss connected to it. To use all 32 interrupts use a 32 input bit concatenate block, when you next click on validate you will see the intr input width on the AXI Interrupt block update automatically to the correct width.

The AXI controller is very simple then containing a number of 32 bit registers such as interrupt status, pending, enable and clear registers along with interrupt vector addresses to manage the 32 interrupts.

Within the AXI interrupt block we can customise its behaviour, most importantly we can select if we want the interrupts to be level triggered and active high or low.


Once we have configured the hardware as we desire we can build the hardware and export the hardware to SDK if we have not already done this previously.

Within SDK we can create a simple programme which enable us to configure and initialise the AXI interrupt controller and simulate a timer interrupt occurring. Taking this approach allows us to verify in stages our use of interrupts, this stage allows us to demonstrate that we have correctly configured the interrupt controller. Satisfied that this is working OK we can then configure the timer to function and generate interrupts later on.

The first thing we need to do within our software application is include the correct libraries for this example we will need the following


  • stdio.h – Contains the standard input and output functions
  • platform.h – Defines the initialisation and tidy up routines for the MicroBlaze
  • xparameters.h – Contains the address and configurations of need for the system
  • xstatus.h – Contains the status definitions used
  • xintc.h – Contains the API for using the AI interrupt controller
  • xil_exception.h – Contains the API for MicroBlaze exceptions

With the correct libraries included the next stage is to write three functions

  1. Interrupt Example – This one is called from the main() function and controls the demonstration
  2. Interrupt set up – A standalone function which configures the AXI interrupt controller and the microblaze exceptions
  3. Interrupt Service Routine (ISR) – This is the function called when the interrupt occurs

As this is a simulated interrupt the ISR simply terminates the programme after printing a message out over the UART when I ran this I got the following output on my terminal.


I have added the software application I wrote to my GIT Hub   repository for download if you want it. The next blog on the ARTY will look at the using the AXI timer and the determining the interrupt latency.


Arty – SDK Hello World


When we left the hardware build we had just exported the HDF and bit file to SDK, initially this will have exported the required information to a directory local to the Vivado project.

With the project exported we can close down Vivado and open SDK, if this is the first time you have opened SDK you will be asked for the workspace you wish to use. The workspace is the area where your projects and associated software projects like Board Support Packages (BSP) and copies of the hardware definition will be stored.

Within SDK to get this up and running we need to do the following

  • Create a hardware definition project
  • Create a Board Support Package for the hardware definition
  • Create our application – in this case a simple hello world
  • Build the application – this is the simple part
  • Define the debug environment such that we can run the application on the Arty board over the JTAG link.

The first step is to import the hardware definition we just exported from Vivado to do this select file->new-> other from the SDK menu this will open a dialog box, beneath the Xilinx folder as shown below select new Hardware Platform Specification

21On the next dialog box enter your project name, I always prefer to call it project_HW to be clear what it is and browse to the directory within your Vivado project which contains the HDF file. Note this is within the .sdk folder under your Vivado project.


This will create the hardware specification which, will appear under the project explorer on the left side of SDK, as shown below (this does show all three of the elements we need to create a project)


We are now in a position that we can create a BSP for the hardware platform, this contains the drivers necessary for the hardware. We can create the BSP by selecting file->new->board support package this will open a dialog box like below


Enter a project name, notice how it has picked up the hardware platform we just created, for this example we will use the standalone operating system.

This will a settings pop up for the BSP there are no changes we need to make here but this is where we can add in additional options if needed e.g. light weight IP stack etc


We can also on the standalone page select the stdin and stdout for the compiler make sure this is set to uart lite as below.


With this verified you can close the BSP settings and you will see a progress box appear while the software generates the BSP files for your system.

At this point we can then create our application, for this example I am going to use the simple hello world template. We can create the application project by selecting file->new->application project this will open a dialog box where we can select the BSP we previously created the hardware definition and the processor we are targeting (in this case there is only one)




This will create a simple application which will output hello world over the USB-UART, selecting build all will then enable us to build the BSP and the application project such that we get an ELF file which can be downloaded and run on the hardware.  The project is built using the project->build all settings and you will see the ELF file appear under your application project as below


The next stage is to run it on the Arty board, this requires that we remove the jumper on J1 on the arty board such that we do not load the design example already loaded within the QSPI flash.

To run the example we need to do the following

  • Programme the FPGA
  • Download the ELF

Before we can download the ELF we need to create a debug environment such that when we click on it we can download the elf. To do this right click on your application project and select Debug As -> Debug Configurations as below


This will open a dialog box where we can create a new debug environment, we wish to create a new GBD debug application


One you have selected new you will see the dialog box below, you should only need to change the information on page one (most should be auto populated)


Provide a name and If not selected select the Rest Processor from the drop down menu close to the bottom, we also need to click on the Debugger applications tab and uncheck the option ”stop at main() when debugging” this ensures the application will run automatically on download finally then click on apply not debug and then close.


With this completed it is time to connect the arty board to the USB of your PC, this will auto detect and install any software required when it is completed we can progress and test our application. Note it should only ever need to install once.

The first thing to do is programme the FPGA we do this under the Xilinx Tools -> Programme FPGA which will open the following dialog box (you should not need to change anything)


Click on program and you will see the FPGA is programmed, you can confirm this on your Arty board as the done LED will illuminate green.

We are now ready to download our ELF file, click on the bug icon on the top menu and this will use the debug configuration we just created to download the application


Once downloaded you will notice the software runs and the message “hello world” will appear in your chosen terminal programme.

You can find part one here


SDSoC Step by Step Example



Until the release of the Xilinx® SDSoC™ development environment, the standard SoC design methodology involved a mix of disparate engineering skills. Typically, once the system architect had generated a system architecture and subsystem segmentation from the requirement, the solution would be split between functions implemented in hardware (the logic side) and functions implemented in software (the processor side). FPGA and software engineers would separately develop their respective functions and then combine and test them in accordance with the integration test plan. This approach worked well for years, but the advent of more-capable SoCs, such as the Xilinx Zynq®-7000 All Programmable SoC and the upcoming Xilinx Zynq UltraScale™ MPSoC, mandated a new design methodology.

Link here 


ZedBoard Part 1 Introduction


How exciting! I just took delivery of my very own ZedBoard — a low-cost development board for the Xilinx Zynq-7000 All Programmable SoC (AP SoC).

As I’m sure you will recall, the Zynq itself combines a full hard core implementation of a dual ARM Cortex-A9 microcontroller subsystem (running at up to 1GHz and including floating-point engines, on-chip cache, counters, timers, etc.), coupled with a wide range of hard core interface functions (SPI, I2C, CAN, etc.), and a hard core dynamic memory controller, all augmented with a large quantity of traditional programmable fabric, some programmable analog functionality, and a substantial number of general-purpose input/output (GPIO) pins. In addition to the Zynq, the ZedBoard contains everything necessary to create a Linux, Android, Windows, or other OS/RTOS-based design. Additionally, several expansion connectors expose the processing system and programmable logic I/Os for easy user access.

For my first blogs about the Zynq, I thought would write a simple guide explaining how the design tools integrate and what is needed to get the board up and running with a simple application that can be built upon in both software and hardware terms.

Creating an All Programmable SoC design requires a little more effort than developing a traditional logic-based FPGA design; however, it is still pretty straightforward and the tool chain provides good guidance. To create an All Programmable SoC design, you will need to use, as a minimum, the following:

  1. Xilinx Platform Studio: This is where you create you processing system, be it a PowerPC, Microblaze, or — in this case — the Zynq’s dual core ARM Cortex-A9. Here you define the configuration, interfaces, timing, and address ranges; everything needed to generate a processor system. The output from this process is an HDL netlist defining your system.
  2. Xilinx ISE: Most FPGA engineers are familiar with this tool, which takes your HDL design — including the XPS netlist — and generates the required BIT configuration file.
  3. Xilinx Software Development Kit (SDK): This is where the software that will run on the processing system is developed. To correctly generate the software, the SDK needs to be aware of the hardware configuration of the system.
  4. Impact: Performs the loading of the BIT configuration bitfile into the system.

All of these tools can be used in isolation to create an All Programmable SoC. Rather helpfully, however, Xilinx PlanAhead is capable of integrating them together, thereby allowing for a much simpler development process. It is using this PlanAhead approach that I will focus upon for the rest of this blog.

Zynq devices are split into two distinct sections: the programmable logic (PL) section and the processing system (PS) section. This blog will predominantly focus on implementing a PS system augmented with a simple logic design within the PL fabric, thereby allowing me to demonstrate an implementation that uses both sections of the Zynq.

The first step in this development is to open PlanAhead and create a new RTL project as shown in the following two images



This is fairly straightforward since — as you initially have no existing RTL, IP, or constraints — you can simply keep on selecting the “Next” option until you reach the “Device Selection” dialog. It is at this dialog that you should select the board option — not the device — and target the Xilinx ZC702 Evaluation board as shown below. Yes, I know that this is not the ZedBoard, but we will return to deal with this point in my next blog


Once the project has been created, you will be presented with the default screen in PlanAhead, at which point you need to add a source to the design. You can do this by selecting the “Add Sources” item under the “Project Manager” options in the “Flow Navigator” area, which should be on the left-hand side of the screen as shown below


As we are currently interested in getting the processing system side of the Zynq up and running, select the “Add or Create Embedded Sources” option as shown in the following image. As we shall see, the general-purpose input/output (I/O) for our programmable logic will be called up here as well


This will open yet another dialog, from which we can select the “Create Sub-Design” button as shown in the image below


OK, we’re almost there. Although this may seem a little complicated, it’s actually pretty easy once you get the hang of it. In my next blog we will complete the configuration and use PlanAhead to generate the bitstream and download it into the device.


A Double-Barreled Way to Get the Most from Your Zynq SoC



One of the many benefits
of the Xilinx® Zynq®-7000
All Programmable SoC is
that it is has two ARM®
Cortex™-A9 processors
onboard. However, many
bare-metal applications and simpler operating
systems use only one of the two
ARM cores in the Zynq SoC’s processing
system (PS), a design choice that can potentially
limit system performance.
Depending upon the application in development,
there could, however, be a need
to have both processors running bare-metal
applications, or to run different operating
systems on each of the processors. For
instance, one side could be performing
critical calculations and hence running a
bare-metal/RTOS application while the second
processor is providing HMI and communications
using Linux.

Link here