The ability to perform real-time, low-latency and deterministic processing at the edge is increasingly important for a range of applications, from autonomous vehicles to vision guided robotics and intelligent surveillance systems.

Processing at the edge is required for four main reasons availability, latency, security and determinism. Should wireless communications be used to communicate to and from a cloud service where the processing is performed, connection to the cloud service cannot be guaranteed. As you might experience service outages and/or signal blackspots created by buildings or natural vegetation. Of course, processing time and decision making for sensitive data in the cloud will also increase the latency and decrease the determinism of the response making it unsuitable for real time safety critical decisions.

Edge processing addresses the availability, latency and determinism challenges. However, it can present additional challenges as, normally, the computational power available at the edge is much lower than is available in the cloud.

In this article, we will address the low power and high performance challenges of an edge processing system by implementing a real time human detection application using a Zynq UltraScale+ MPSoC device on an Aldec TySOM-3A-ZU19EG embedded development board.

Zynq UltraScale+ MPSoC Heterogeneous System on Chip (SoC) Device

Using heterogeneous System on Chip (SoC) devices, like the Zynq UltraScale+ MPSoC, enable the user to address the challenges of implementing low latency, deterministic processing at the edge. Unlike traditional processor-based solutions, heterogeneous SoCs are divided into two elements; a processing system which contains high performance ARM processor cores and programmable logic which provides structures based on the latest Xilinx FPGA fabric.

The flexibility provided by the programmable logic IO structures enables the implementation of any-to-any interfacing. This frees the designer from the IO constraints enforced by application specific standard part (ASSP) devices. For example, thanks to programmable logic’s IO flexibility, several MIPI interfaces can be implemented both as TX and RX and supporting a range of data rates, data lanes and data types. The flexible implementation of this logic enables the solution to be upgraded as sensor technology evolves.

Outside of the programmable logic IO structures the parallel nature of programmable logic itself enables the implementation of a true image processing pipeline. This image processing pipeline will be implemented in parallel due to the massively parallel nature of the programmable logic. This means the image processing pipeline is implemented internally to the programmable logic, removing the need to use DDR memory to store processing stages. This reduces latency and increases the determinism, as there is no need to compete for access to a system resource in DDR.

When developing solutions for a heterogeneous SoC we can leverage embedded Linux running on the software processing side of the device, while development of the programmable logic can take advantage of vendor-provided IP and increasingly high level synthesis; which allows C/C++ to be implemented in programmable logic.

One of the more exciting total system solutions is the use of system optimizing compilers such as SDSoC and Vitis which enable functions to be accelerated from the processing system to programmable logic leveraging the OpenCL framework. This enables system architects to further leverage the programmable logic to accelerate algorithms, this is especially true for accelerating Deep Neural Network applications thanks to the Xilinx Deep Learning Processor Unit (DPU).

Implementation

One example which demonstrates the capabilities of Zynq UltraScale+ MPSoC device at the edge is implementing a real-time human detection that can be used in surveillance cameras, ADAS, smart cameras, etc.

Such applications require the ability to configure and receive images from a camera, process the images and run convolutional neural networks (CNN) on the processed image. These processed images can then be output over HDMI and written to solid-state memory. To be able to demonstrate the algorithmic performance on programmable logic quickly and easily, Aldec’s TySOM-3A-ZU19EG development board along with FMC-ADAS (for capturing camera images) and FMC-NVMe (for recording the processed / raw data) can be used. These development boards enable the development team to hit the ground running. The following image shows an overview of the design example for this blog.

Accelerating your design in this manner enables you to demonstrate early progress to internal and external project stakeholders.

The implementation of a real-time edge processing application requires significant resources to achieve the desired performance. The TySOM-3A-ZU19EG, which features the largest programmable logic in Zynq Ultrascale+ MPSoC devices, provides the designers with over 500K LUTs and 1M Flip Flops, exactly what is needed to implement such a challenging application. In addition to the largest Zynq UltraScale+ MPSoC device, TySOM-3A-ZU19EG provides a wide range of peripherals such as USB 3.0, USB 2.0, Ethernet, QSFP+, mPCIe, DisplayPort, HDMI IN/OUT, Wi-Fi and BLT, SATA, CAN, Pmod, UART, JTAG and FMC HPC connectors.

Capturing the video is done by the FMC-ADAS which includes five FPD-Link III connectors, frequently used for ADAS and bird’s eye view applications. A base platform can then be designed using Vivado which implements the image processing path; as a crucial part of the image processing path is making the video stream available to the processor system by storing frames in the Processor System DDR Memory. Higher level frame works such as GStreamer can then be used by the Processing System to work with the image stream.

To provide the NVMe SSD interface, Aldec’s FMC-NVMe is used. It provides four NVMe interfaces, which can each be stacked up to eight cards deep. This feature enables us to use up to 32 SSDs. Aldec provides a detail solution page for NVMe data storage using this FMC daughter card.

The PCIe capabilities of the programmable logic are used to perform reads and writes. Drivers for the PCIe access to the NVMe will be provided by the embedded Linux operating system.

Of course, to display the output image on a HDMI monitor the Processor System DDR memory is accessed by the Xilinx Video Mixer IP block. This block can mix up to four video layers, ideal for the creation of overlays and graphics on the output video. For example, frame rate information and bounding boxes around detected objects.

This Vivado hardware design can be combined with an embedded petalinux solution targeting the TySOM board to create an acceleration platform used by SDSoC or Vitis. This platform can then be used across several projects to implement software accelerated solutions ranging from embedded vision applications to deep learning, as is the case in this example.

Using this acceleration platform in SDSoC or Vitis, it is possible to accelerate neural network inference. This acceleration will implement Xilinx DPUs within the programmable logic when the application is compiled. There are several different instantiations of the Xilinx DPU depending on the required resource utilization and performance goals. For this example, two of the largest and highest performance DPUs were implemented. Both are capable of 4096 operations per clock, and can be clocked at 300 MHz. TySOM-3A-ZU19EG enables us to implement these high performance DPU architecture thanks to the high capacity of programmable logic provided in the board’s Zynq Ultrascale+ MPSoC ZU19EG device.

The application software is then executed taking advantage of the platform image processing pipeline to capture and display an image, while the neural network — which is processing the image frames for people detection — is implemented on the Xilinx DPUs in the programmable logic. This enables a 720P image stream to be processed and detect people within the image stream at 30 FPS while at the same time writing to the NVMe SSD.

When the project was implemented using SDSoC only about one third of the TySOM 3A’s total logic resources was used.

This project demonstrated the capabilities of using a heterogeneous SoC to create edge processing applications which require low latency and determinism.

The use of Aldec’s TySOM-3A-ZU19EG embedded development kit along with the company’s FMC-ADAS and FMC-NVMe boards enabled us to de-risk the implementation of the algorithms and gave us the ability to start development early.

SDSoC enabled us to leverage the acceleration platforms to implement deep learning applications using only a software development environment.

The reference design for the human detection example at the edge was provided by Aldec, and is available to TySOM users. For further information, please contact Aldec

In this blog I am going to demonstrate how we create a PetaLinux embedded Linux solution for our Zynq design. In this case we are going to use the Cora Z7 as the target development board.

To create an embedded Linux solution for our Zynq, Zynq MPSoC or MicroBlaze solutions we start with a hardware design in Vivado.

For this application we are going to connect the Zynq Processing System (PS) to the LED and Push Buttons which are on the Cora Z7. This will make for a nice example in our next blog on interfacing between the PS and Programmable Logic (PL).

This connection is made using a AXI GPIO IP located within the PL, this is then connected to the PS Master AXI port as shown below.

Once this block diagram has been completed we need to implement the Vivado design and export the XSA with the bit stream included.

Export the XSA to the project directory, this XSA will inform our embedded Linux solution about the configuration of the hardware.

With the XSA exported the next steps take place all within PetaLinux, the first thing we need to do is create a new project.

Within our Virtual Machine, the next step is to open a terminal window and create a new project using the command.

petalinux-create --type project --template zynq --name cora_z7

This will create a new project targeting the Zynq architecture with a project name of cora_z7.

The next step is to change directory into the newly created project, and then configure the project for the Cora Z7 and our design using the XSA just created in Vivado.

petalinux-config --get-hw-description=/<location of XSA>

This will open the PetaLinux system configuration

In this case we do not wish to make any modifications, as such the we can select exit.

If you want to explore the kernel and rootfs settings you can use the commands

petalinux-config -c kernel

petalinux-config -c rootfs

As we do not need to make changes to either the kernel or the rootfs we can now build the PetaLinux operating system using

petalinx-build

Once the build process has finished, it may take some time we can then try the image on our Cora Z7 hardware using the commands

petalinux-build --jtag --fpga

petalinux-build --jtag -- kernel

This will program the Zynq device with the bit stream and then download the kernel.

Watching the boot output on a serial terminal will show you the Linux image booting on the Cora

If the above steps work and we have finished our testing and development we can then package the build objects to create a Bin file for booting from memory.

petalinux-package --boot --fsbl zynq_fsbl.elf --uboot uboot.elf --fpga system.bit

We can also package the PetaLinux project as a BSP such that if we wish to make changes to the PetaLinux system in the future we can use the BSP to create a new project, which is already configured correctly for our system.

Unlike all of the other commands this needs to be executed outside the project

petalinux-package --bsp -p <project location>

No we have successfully built a Embedded Linux OS which is up and running on the Cora Board.

Next time we will look at how we can interface between the PS and PL when we are using PetaLinux.

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

Get the Code: ATaylorCEngFIET (Adam Taylor)

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

Having demonstrated how to get create a PetaLinux build environment, we are now in position to be able to start creating embedded Linux solutions.

As such in this blog we are going to look at the different elements which are included in a PetaLinux build and which might need configuration.

As always we will start with the highest level element and its configuration.

System — The main PetaLinux element which enables us to configure the highest level of our embedded Linux solution.

Elements which we may configure at the system level include, location of the RootFS e.g. INITRAMFS or External such as SD, USB etc. Using the system configuration we can also use an external Linux kernel or out of build kernel if desired.

We can also configure the hardware elements such as stdin/stdout and baud rate.

In the PetaLinux build flow the sytem configuration dialog is opened following the petalinux-config get-hw-definition or using the command petalinux-config

Kernel —The operating system and as such it is heart of our embedded Linux solution

Elements we may need to configure in the kernel as part of our PetaLinux project are networking support, device drivers, libraries routines, file systems and memory management options. Within our PetaLinux project we can customize the kernel using the commands petalinux-config -c kernel

Root File System — The rootfile system provides the embedded Linux system with the capability to boot, restore, repair and recover the system.

Within the RootFS configuration we are able to ensure any custom applications we have created are included in our File System or not.

We are also able to configure any desired packages for our embedded Linux solution including OpenAMP, OpenCV, QT etc.

Device Tree — The Kernel needs to be able to understand its hardware configuration. Embedded Systems are often highly configurable at the hardware level. As such the Device Tree provides information to the kernel, including address, interrupt numbers, driver bindings etc.

In PetaLinux when we apply the hardware definition the PetaLinux creates the device tree structures which are needed. However we may also need to add in additional elements to the device tree. To do this we can edit the device tree DTSI (device tree source include) available under the <project>/project-spec/meta-user/recipes-bsp/device-tree/files

In the example below you can see the DSTI file updated to enable the use of SPIDEV with spi0.

These device tree source and include files are then compiled into a device tree blob which is included with the kernel image.

Having looked at the different elements of the PetaLinux build process and what we may need to configure in our next blog we will create our first embedded Linux solution.

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

Get the Code: ATaylorCEngFIET (Adam Taylor)

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

To install PetaLinux our Linux machine needs at least the following

• 8 GB RAM
• 2 GHz CPU
• 100 GB free HDD
• OS — Red Hat Enterprise Workstation/Server 7.4 / 7.5 / 7.6 (64-bit)
• OS — CentOS Workstation/Server 7.4 / 7.5 / 7.6 (64-bit)
• OS — Ubuntu Linux Workstation/Server 16.04.5 / 16.04.6 / 18.04.1 / 18.04.2 (64-bit)

Due to the large varieties of Vivado / PetaLinux versions I work with, I prefer to create virtual machines on external SSD drives connected to my laptop over USB C. This means I can change between versions with ease and not use all the storage on my laptop.

To create a PetaLinux machine we will need

• Virtual Machine Software — I use Oracle VM
• Ubuntu 16.04.6
• PetaLinux Installer + Pre-Requisites

Lets get started with creating the Linux VM, the first steps having installed the VM software are to create a new machine.

Make sure you allocate sufficient resources to this VM, I allocated 16 GB DDR and 150 GB storage.

Once the new machine is created, we still have a few steps to follow before we can create a boot-able Linux VM.

The first step is to select the machine just created and increase the number of processors the VM can use beyond the default of 1.

With a more appropriate number of processors enabled (dependent on your system), we can start the VM and install Ubuntu.

When the VM is started you will be prompted for the location of the start up disk. This is the ISO we downloaded from the Ubuntu link above

This will provide the the option to try or install Ubuntu, select install and complete the installation. When asked if you want to upgrade, decline the opportunity.

Once the installation is complete we can download the PetaLinux installer from the Xilinx website. To do this you will need to register for a Xilinx account.

With the installer downloaded the next step is to copy the installer into the installation directory.

However, before we can install PetaLinux, we need to make sure we have all of the required packages installed.

Using a terminal window enter the command below to download any missing but required packages.

sudo apt-get install -y gcc git make net-tools libncurses5-dev tftpd zlib1g-dev libssl-dev flex bison libselinux1 gnupg wget diffstat chrpath socat xterm autoconf libtool tar unzip texinfo zlib1g-dev gcc-multilib build-essential libsdl1.2-dev libglib2.0-dev zlib1g:i386 screen pax gzip gawk

After the required packages are installed we are able to install PetaLinux, using the terminal window issue the command

./petalinux-v2019.2-final-installer.run

Once the installation completes to make use of PetaLinux tools we need to first source the settings.sh script in the installation directory.

We are now able to get started using PetaLinux, which we will be looking at in the next blog!

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

Get the Code: ATaylorCEngFIET (Adam Taylor)

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

I thought it would be a good idea to dedicate a special series of blogs looking at PetaLinux, what it is and how we use it.

As such over this PetaLinux edition in addition to this introduction to PetaLinux, we are going to be looking at :-

• PetaLinux Build Environment — How to get started and what tools we need to create a complete PetaLinux deployment.
• PetaLinux Build Components — What are the different elements of the build e.g. Root File System, Image, Device Tree.
• PetaLinux Build Flow — How do we customize the OS.
• PetaLinux Interfacing — How do we interface from the PetaLinux OS to our programmable logic design.

Lets start at the beginning and understand what is PetaLinux? Simply put PetaLinux is a set of build tools which allow us to create an Embedded Linux solution for Xilinx processors (A9, A53 & MicroBlaze) using a x86 Linux host.

At the highest level PetaLinux consists of only seven commands, these commands are used to create projects, applications, boot and deploy the embedded Linux OS.

These commands are

petalinux-create — this command is used to create projects, apps & modules. When creating projects we need to define either a template which can be zynq, zynqMP or microblaze. Alternatively we can define a source which contains a existing PetaLinux board support package.

Most custom projects will start with targeting a processor type, before creating a board support package later in the development.

petalinux-config — this allows configuration of a specific element of the OS e.g. the kernel or the root file system. This also enables configuration of the OS for a new hardware definition using the get-hw-description option.

The get-hardware-description option is a key stage in the development of the embedded Linux solution. This option configures the PetaLinux project for a specific hardware design created in Vivado, this includes configuring U-Boot, the Kernel and the Device Tree.

petalinux-build — this command builds the embedded Linux project, a component of the project or the Yocto e-SDK.

This command builds the PetaLinux project include the Bootloader, Kernel, PMUFW, Arm TrustZone, UBoot, Kernel and the root FS. If desired we can also use this command to build elements of the project e.g. kernel

petalinux-boot — this command enables us to boot the project on our target board using JTAG or to boot the project in the simulation environment in QEMU.

Using QEMU we can emulate the Arm or MicroBlaze cores to run the PetaLinux project. This is great for debugging and ensuring the project actually boots as desired, it is especially useful if modules or kernel drivers have been included in the project.

petalinux-package — at the end of the project build we may desire to package the project to create a boot.bin which can be used in conjunction with the Kernel and RootFS to boot the system. This command can also be used to package the project as a Board Support Package.

Packaging the project as a BSP enables the same settings to be quickly and easily applied to new projects going forward. This is very useful if the same development or custom board is to be used going forward for development.

petalinux-upgrade — this commands provides for the upgrading between different versions of PetaLinux

Using the upgrade command we can take BSPs or projects created in earlier versions and update them to the current release. This can save considerable time when it comes to changing existing project between versions of Vivado.

petalinux-util — this command provides a number of services which are used in development and debugging

This command provides the dfu-util for downloading and uploading over USB along with debugging via GDB, XSDB and JTAG.

Using these commands over the next few special editions of this blog we are going to create and work with PetaLinux solutions running on Zynq and Zynq MPSoC cores.

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

Get the Code: ATaylorCEngFIET (Adam Taylor)

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

In this blog we are going to look a little more in detail at the development flow, targeting industrial an application algorithm. Commonly these industrial algorithms are used in? industrial control applications such as controlling a set point or converting measurements values into a value which can be further processed. Typical algorithms include

· Calendar-Van Dusen — used to convert a reading from a Platinum Resistance Thermometer to a temperature.

· Proportional Integral and Derivative algorithm — used in control applications to achieve a set point for example measuring a temperature and driving a heater to achieve the desired temperature.

Both to these algorithms can be implemented in software however, many industrial control systems require a low latency to ensure control and accuracy. As such accelerating the algorithm using High Level Synthesis is popular choice of course once the algorithm has been written we need to optimise its performance which is where SLX FPGA comes in.

Another benefit of accelerating algorithms in programmable logic is that larger batches of data can be processed and still achieve increased performance.

Creation of both the PID and CVD algorithms can be achieved quickly and easily using floating point maths that can then be synthesised using HLS.

Let’s look at the CVD algorithm and its implementation, mathematically this can be very complicated

R=R0 ×(1+a×t+b×t²)

Re arranging for temperature gives

t= (-R0×a+√(R⁰²×a²-4×R0×b×(R0-R)))/(2×R0×b)

However, it can be implemented using polynomial approximation in C as shown below.

Running this code through Vivado HLS with no optimisations, produces an interval between calculations of 4225 clock cycles and resource utilisation of approximately 3%.

To get started with SLX FPGA the first thing we need to do is create a new project, we can then start adding in the source and test bench code. Like any development tool we want to ensure the correctness of the algorithm before we begin optimisation.

Once we have the project name entered, we can then select the target platform, selecting this is mainly for the SDSoC / VITIS flow. If we want to use a standard HLS flow, we can select this once the project has been created.

With the project created, we will see the configuration settings dialog open for the project. It is using the configuration setting we control

· Vivado HLS or VITIS / SDSoC flow

· Project files for compilation and linker flags

· We can also identify the top function, the desired clock frequency and synthesis and estimation models

Within the configuration page we can also define the number of currently occupies resources in the platform, this is very useful for a SDSoC / SDAccel based flow.

We can also define the size of arrays we wish to partition to improve throughput, arrays below the complete partitioning limit are fractured.

We can also identify which functions are candidates for acceleration hardware, by defining he candidate threshold.

For this example, we are going to be using the HLS flow to implement the CVD algorithm. To identify the best HLS optimisations, we are going to use the following processes from the tool bar

1) Find Parallelism — Identify parallel data and pipeline parallelism.

2) HLS Hints — Review the HLS recommendations which include pipelining and partitioning.

3) HW Optimisation and Processing — Allows optimisation of the HLS suggestions.

4) Generate the HLS aware code — Insert the HLS optimisations into the source code

5) Synthesise the project — Implement the project with the HLS optimisations.

Clicking on the HLS Hints button will run first the find parallelism and then display the HLS Hints. HLS hints show several opportunities for optimising the presented source code, including the data-level pipelining and partitioning of arrays.

With the HLS hints available, we can optimise using the hardware optimisation and partitioning dialog. This enables us to determine the number of times identified loops are unrolled, we can of course trade performance for area to achieve a lower initiation interval when we define this.

As the batch size in this example is 128 samples we can if we desire and resource allow change the loop unroll factor to 128.

When this code was implemented using Vivado HLS via SLX FPGA. The performance was significantly improved over the original un-optimised code, producing a latency of 100 clocks compared to the original 4225 clocks. Of course, this implementation does use more significantly more logic resources at approximately 20% of the device.

As we can see running our code through SLX FPGA enables us to quickly and easily implement industrial control algorithms using HLS.

If you are interested in seeing a demo of SLX FPGA, the SLX FPGA team will be attending XDF in The Hague on the 12th & 13th October.

Yesterday in the keynote at XDF19, it was announced the new unified software environment would be called Vitis and most exciting of all it would be available from the end of the month be heavily open source based and free.

Fortuitously, when I registered which sessions I wanted to attend at XDF, I had selected most of the unified software environment talks. So in the reminder of this blog we will take a look at the important Vitis details.

The first thing to point out is the Vitis is not limited to only ACAP development it is also supports exiting Zynq, MPSoC and RFSoC devices as well. Meaning, we can start leveraging its development advantages in our existing developments.

Vitis is a unified software environment for all Xilinx platforms, which means we can use Vitis to develop applications for Alveo Accelerator cards, embedded platforms or FPGA in the cloud. Changing the target requires only changes to the make file.

To achieve this, Vitis uses a stack based architecture across four layers:

• Vitis AI — Domain specific architectures enabling TensorFlow and Caffe frameworks to be optimized, compressed and compiled to run on a Xilinx devices in minutes.
• Vitis Accelerated Libraries — Several hardware accelerated libraries including video, image processing, AI, fintech and security.
• Vitis Core — Includes the Xilinx Runtime library, compilers, debuggers and analyzers.
• Vitis Base — Platform definition of the hardware including IO abstraction.

One of the key elements of Vitis is the Xilinx Runtime (XRT), this is the same XRT which has been used for several years as part of the PCIe based accelerators like the Alveo boards.

XRT is combination of a runtime software layer and kernel driver that allows software to interact with programmable logic and Versal accelerators.

The development flow in Vitis is clearly defined for hardware and software:

• Hardware development flow uses C or C++ and high level compilers — the actual contents of the accelerator is determined by the SW calling hardware optimized libraries, RTL functions or translation into hardware directly. System composition and connectivity are defined by command lines
• Software development flow is identical to a standard software build.

In a change from previous tools, Vitis is designed to plug in directly with popular open source development and build tools.

To get going with the new tool, Xilinx have launched a developer area at https://developer.xilinx.com. Here, you can find 30 articles and documents across a range of applications showing how we can leverage Vitis.

It goes without saying that once Vitis is available, we will be heavily focusing on it in the blog as we explore how we can use to accelerate out Zynq, MPSoC and eventually Versal designs. Until then, stay tuned!

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

Get the Code: ATaylorCEngFIET (Adam Taylor)

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

This week, we are going to look at how we can work with the HLS analysis perspective, so we can understand where our optimizations will have the best impact in our HLS source.

The analysis perspective is populated with information once we have run HLS synthesis and presents information regarding the hierarchy, resource utilization and most importantly latency of our design.

For our first example, let’s take a look at the loop merge example from last week. With individual loop the latency is 353 clocks, between the ability to process a new input, this is reported in the synthesis view; however, if we want to optimize the performance, we need to know a little more about where the bottlenecks are.

This information is provided by the analysis perspective.

Within the analysis perspective, we will several windows that enable us to optimize further our design.

Taking the loop merge example from last week under the performance profile, you will notice three loops contained within the accum function. For each of the loops, the total latency is provided, which is the iteration latency multiplied by the trip count.

When it comes to optimizing the performance, we first want to focus upon the iteration latency. This is the time taken for each cycle of the loop to be implemented.

Once we have optimized the latency of each loop iteration, we can then work on optimizing the number of times the loop executes, e.g. the trip count.

In the case of the loop merge example to increase performance, the first step is to decrease the number of clock cycles required for each iteration of the loop.

To understand more about what operations in a loops iteration increases the latency, we can use the schedule viewer.

The schedule viewer allows us to see not only the operations but also cross probe to the source to understand which line of code causes this operation.

In the example below, you can see the load operation due to the read from the block RAM holding the values of variable A increases the latency. This takes over one clock cycle resulting in a increased latency.

We can use this information to fracture the BRAM, which contains the variable A. This is achieved by using an array partition pragma:

#pragma HLS ARRAY_PARTITION variable=a complete dim=1

Re-synthesizing the design now shows a reduced overall latency as the latency of loop_1 has been reduced by one third to 100 clocks. As each iteration of loop one now takes two clocks compared to the previous three clocks. However, the overall latency is still high at 303 clocks.

Exploring the schedule view in the analysis perspective this time if loop_1 is expanded show 50 entries for variable A as it has been completely fractured. It will also confirm the iteration latency is now two clocks for the loop.

If we apply the BRAM partition pragma to variable A and merge the loops as we did last week, we will achieve better performance than we do when just the loops are merged.

Reducing the iteration interval from 102 clocks previously to 52 clocks. Overall this is a very significant reduction from the original 354 clock initiation interval.

Of course, as we have optimized for performance, we have traded increased logic resources for performance. But in this simple case, we have been able to increase the performance without unduly utilizing significant logic resources as such the trade-ff is very acceptable.

Hopefully now you understand a little more about how we can use the analysis perspective to optimize our HLS design. It really is very powerful and easy to use!

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

Get the Code: ATaylorCEngFIET (Adam Taylor)

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

As such, our HLS source code in either C or C++ tends to include several loops or nested loops. When it comes to optimizing, performance loops are one on the places we can start exploring optimization.

By default, HLS loops are kept rolled. This means that each iteration of the loop uses the same hardware. Of course, this provides the worst performance as each iteration is sequential.

Let’s take a simple accumulator, as shown below.

With no optimization, we will notice that in the analysis view the implementation is sequential. This can be confirmed by looking at the trip count, which reports the number of iterations for the loop and the initiation interval. The initiation interval is the number of clocks between then the module can accept a new input values.

To get optimal throughput, we want to ensure initiation interval is a short as possible.

To increase performance, we can unroll the loop and implement parallel implementations provided the loop bounds are static.

When this is synthesized, we will see a significant reduction in the Initiation Interval.

There is no trip count defined as the loop is fully unrolled.

When we unroll loops, we are gaining a higher performance for increased logic utilization.

Of course, there may be times when we are unable to work accept the performance of the rolled loop but unable to accommodate a fully unrolled loops logic demands.

In this situation, we can partially unroll loops, by defining a unroll factor. For an example, let’s change the size of the accumulator.

By setting the unroll factor we can control the amount of parallelization of the loop.

The analysis report will show the factored unrolled performance. In this case, tt takes half the latency of the rolled example.

You will also see this in the schedule viewer. Under the schedule viewer, you will see implementations of the algorithm.

When we partially unroll the code, the HLS tool will implement an exit check in the loop in case the unroll factor does not result in a integer. However, if it is an integer, we can skip the exit check.

But how do we handle nested loops for example if we are doing matrix operations or image processing?

In this case, we have several options, although it depends on how we implement our loops. To get the best performance (lowest latency) when working with nested loops, we want to create a perfect nested loops.

In a perfect nested loop, again the loop bounds are constant and only the inner most loop contains any functionality.

In the case of a perfect loop, we can flatten the loop merging the outer and inner loops — enabling better performance when synthesized. A flattened loop will have a rolled trip count of n * m where n and m are the number of iterations of each loop.

If we have several loops implemented sequentially, we can also merge them.

Merging loops differs from flattening loop. In flattening loop, we are merging nested loops; when merging, we are merging several independent loops.

When loops are merged, the maximum bound constraint is used.

If we want to merge the loops, there are a few constraints we need to consider first. We cannot merge loops that have FIFO accesses, variable bounds or execution side effects.

Let’s take a look at a very simple example of a loop merge, the code for which can be seen below.

When this code is synthesized with no optimization, the latency and trip counts are:

However, if we take the opportunity to merge the three loops:

The results when all three loops are merged can be seen below a much lower overall latency.

It is not just loop unrolling that we want to explore when optimizing our design for HLS. We also want to look at pipe-lining and memory partitioning, among others. I will do similar in depth deep dives soon!

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

Get the Code: ATaylorCEngFIET (Adam Taylor)

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

SLX FPGA was created to help address the challenges software engineers face deploying C/C++ applications on to programmable logic targets using High Level Synthesis (HLS). These challenges include detecting parallelism within the design, and optimizing the design to be able to leverage the parallelism for increased performance.

This optimization is achieved by identifying and inserting appropriate pragmas to provide level of optimization desired.

To perform the optimizations, SLX FPGA analyses the users HLS C Design and identifies Data Level Parallelism (DLP) and Pipeline Level Parallelism (PLP) structures within the HLS design. FPGA also determines the software call graph, read and write accesses to local, heap and global variables along with providing a holistic view of memory accesses.

To generate the suggested optimizations SLX FPGA uses three stages

• Check for synthesizability errors and guide the user through on how to fix them (see the synthesizability check and recommendation in figure 1 above)
• Determine the Data Level and Pipeline Level Parallelism structures in the design.
• Add the appropriate pragmas for optimal latency, throughput, or area.

Let’s take a look at a simple example implementation of a AES 256 encryption. algorithm. The initial implementation of the HLS code without any pragmas or other optimizations resulted in the following latency and resource utilization.

This original code is therefore capable of processing a new AES Encryption every 1888 clock cycles when implemented in programmable logic. However, there exist several potential optimizations in the code which could be made in the code e.g. loops unrolled, and block RAMS partitioned.

Running the analysis in SLX FPGA on the AES Code (input code is here) produces the following results, identifying several potential optimizations.

This analysis, shown above as SLX hints also breaks down the execution percentage of each element within the design. For example, in the above analysis you can see main loop in the AES Encryption function accounts for 66% of the execution time. While the loop which can be accelerated by pragma insertion accounts for 60% obviously making improvements here will yield big rewards in performance.

With the analysis completed we can then proceed to the hardware optimization and partitioning which is where we can enable or disable pragma suggestions. We can also change parameters at this stage such as unroll factors if we are willing to trade of additional logic resources for performance.

Once we are happy with the optimizations we can generate the code, as the generation progresses we will see both the original source code and the generated code side by side. This view is really useful as it allows us to see the location of the pragma insertions.

When this optimized design was completed, we see a significant increase in performance.

Compared to the original latency, the new design requires only 19% of the original non-optimized latency.

While the resource requirements have increased to provide the performance again the logic footprint of the design is still very compact.

What is interesting to me having worked considerably with HLS over the years is how easy the insertion of pragmas was with SLX FPGA. HLS optimization can be challenging, iterative and time-consuming process, SLX FPGA made this much simpler.

This is especially true for engineers new to HLS or those from a non-FPGA development background who may not understand the internal device structures necessary to optimize the HLS design. Using SLX FPGA this analysis and optimization process becomes the click of a few buttons and reviewing the recommended optimization.

For advanced HLS engineers, SLX FPGA can be used as a double check to see that there wasn’t any performance that the engineer missed or to simply move the HLS design into FPGA faster if they are not familiar with the algorithm.

I am going to keep experimenting with this tool across a few more use cases to learn a little more about it and its capabilities!

If you are interested in seeing a demo of SLX FPGA, the SLX FPGA team will be attending both FPGA World on the 17th and 19th of September in Stockholm and Copenhagen and XDF in San Jose on the 1st to 2nd October.