MicroZed Chronicles: Partial Configuration Introduction

Editor’s Note: This content is republished from the MicroZed Chronicles, with permission from the author.

Getting the most efficient utilization of our FPGA does not mean that we need to have the logic resources dedicated to all use cases. We could, for example, have several different FPGA designs which are loaded in as required with one FPGA implementing several different functionalities. This could be the case in image processing or signal processing pipelines for example. Often when we examine the contents of these FPGA designs, however, only a small element of the FPGA design is different. Take for example an image processing algorithm or signal processing filter. In these cases, it is much faster to simply reconfigure the element of the FPGA design that needs to be changed. 

This is where partial reconfiguration comes in handy because it allows us to reconfigure a small element of the FPGA design at run time, while the rest of the FPGA keeps operating. 

Partial reconfiguration allows designers to move to fewer or smaller devices, reduce power, and improve system upgradability. Only the necessary functionality is loaded in at any point in time so there is more efficient use of the silicon.

In our Xilinx FPGA designs, partial reconfiguration is called DFX or Dynamic Function eXchange (DFX). We can do DFX using simple RTL designs and block designs. While Xilinx provides the IP to manage DFX, there are several terms we first need to understand. 

• Configuration library – The store of partial configuration bit streams.
• Fetch path – The path from the ICAP to the configuration library.
• Reconfigurable partition – The actual element of logic which is reprogrammed.
• Static logic – The logic which is not dynamically updated.
• Virtual socket – Reconfigurable partition, plus logic which enables the reconfiguration.
• Virtual socket managers – These connect to a single fetch path.

To ease implementation of DFX in our FPGA and SoC designs, Xilinx provides several IP blocks.

• Dynamic Function eXchange Controller – Implements a virtual socket manager which controls one virtual socket and associated fetch path.
• Dynamic Function eXchange Decoupler – Provides logic isolation between the static design and the reconfiguration partition.
• Dynamic Function eXchange AXI Shutdown Manager
• Dynamic Function eXchange Bitstream Monitor

Most importantly, we can implement DFX in any version of Vivado. No special license is required. We can target any device, though DFX is not supported in some of the smaller Artix and all Spartan-7 devices.

To help get started, I have created a step-by-step lab which looks at a simple application that can change the speed LED flash on the KCU105 board. The same approach can be undertaken for any supported device / boards and will demonstrate the basic flow and technique. 

The instructions are available here in a high-level overview of the steps involved.

Create an RTL project targeting the board. Add in the RTL files for the base design including the nominal element for the reconfigurable partition. 

1. Convert the project into a DFX project
2. Create a partition definition 
3. Open the DFX Wizard and assign the reconfigurable modules to the partition just created
4. Create the configurations 
5. Create the run configurations
6. Close the DFX Wizard and start an implementation 
7. Program in the main design 
8. Update the design with the reconfigurable modules and see the output change 

I observed the video below when I ran this on my KCU105 board.

https://youtu.be/XGM1Io9575w

Now we know the basic flow of DFX, the available IP, and the terminology. In the next blog, we will look at how we can do DFX using a more commonly used block design.