Making hardware more like software

Here’s a way to partially or fully reconfigure an FPGA without rebooting the operating system.
One of the biggest advantages of field programmable gate arrays (FPGAs) is the ability to change the functionality of the silicon by loading a new configuration file into the device. Controlling the configuration of the FPGA is usually done by an on-board processor that communicates to a flash-based configuration storage device.

The configuration mechanisms are usually custom to the specific FPGA and require specialized on-board connections and rules. Overall, the user usually embeds the flash device on-board forcing an estimate of the configuration size before storing all possible configuration streams of the FPGA on that device. In this article, we propose a device architecture and software method that alleviates this problem and also provides many advanced features to the processor.

Architecture description
Figure 1 shows an FPGA architecture with an embedded hardened processor. The processor has multiple hardened ports: Ethernet and DDR, while it communicates to the FPGA through a high-speed bus. In addition, the processor has an on-chip connection to the control (Config) block of the FPGA. The control block enables all configuration schemes for the FPGA and controls the startup sequences of the FPGA. The chip is divided into two regions such that all hardened peripherals connected to the FPGA including the processor can operate independently of the FPGA (the processor is live while the FPGA is configuring, reconfiguring, or in the user mode running the application).


Making hardware more like software
Click on image to enlarge. 

Additionally the FPGA is assumed to have two key features:
The ability to be configured (and reconfigured) without powering down the processor.

The ability to be partially reconfigured while part of the FPGA is running.

Typically this system is built as an embedded system with a two-chip solution. The benefits of a single-chip system over a dual-chip system are well known especially if the two chips can run independently. The processor usually runs an embedded operating system (such as VxWorks). Each of the hardened peripherals has its own device driver running on the embedded operating system. We propose two additional device drivers that will:
Control the port connecting the processor to the control block of the FPGA and control the function of full configuration of the FPGA.

Control the port connecting the processor to the control block and control the function of partial reconfiguration of the FPGA.

The purpose is to map the configuration of the FPGA into software application programming interfaces (APIs) on the processor. The actual bitstream for configuration could be stored remotely off-board if the processor has access to any of the hardened peripherals as needed. Figure 1 shows that the processor can access the data stream from any device connected on the Internet through the Ethernet port.

Use of FPGA

The FPGA can be fully or partially reconfigured while the processor is running as shown Figure 2. Using full reconfiguration, the user can change the complete image of the FPGA and setup new regions to be used for subsequent partial reconfigurations.


Making hardware more like software
Click on image to enlarge.

The FPGA can be used for many specific purposes in embedded systems. Two popular uses are hardware acceleration of compute-intensive algorithms shown in Figure 3 and processor peripheral expansion, shown in Figure 4.

Making hardware more like software
Click on image to enlarge. 

Making hardware more like software
Click on image to enlarge.

To maximize usability of the FPGA, partial reconfiguration is both of the above cases. For example, in the I/O peripheral case, as shown in Figure 4, a protocol can be switched from eSATA to Fibrechannel while the SDI channel is running. This can be achieved by partially reconfiguring the soft implementation of the protocol layer. In the co-processor example, the algorithm is being switched as well as being accelerated in the FPGA depending on the algorithm flow in the processor. In addition, if it is a multithread or multiprocess system, one thread can reconfigure a section while another thread is using another section of the FPGA for acceleration.

FPGA configuration (partial or full) can be mapped as device drivers in the embedded OS. An additional API can be written in software in the embedded OS to control the dynamic switching capability described. This isolates the hardware implementation. The advantages of this overall platform and the software implementation are:
The application developer is isolated from hardware implementation. The software code does not need to know that the FPGA is being reconfigured dynamically to expand the peripheral set. The hardware can be changed without changes to the user application code but with minor changes to the device drivers.

The configuration files for the FPGA can be stored off-board given maximum security. Special encryption techniques can be used within the processor to decrypt the configuration file if required.

One key point of the platform is preselecting the types of peripherals that can be placed on the FPGA or preselecting the algorithms being accelerated. This means that no dynamic compilation of Verilog/VHDL code is being done on the system. All FPGA images (full and partial) are assumed to be compiled before hand. Although the latency of loading and unloading configuration files into the FPGA is significant, the system assumes that it is done infrequently during system operation. The main purpose is two-fold:
Saving area on the FPGA by using partial reconfiguration of known protocols or acceleration algorithms into predefined FPGA regions.

Mapping the configuration function and the transformed regions into device drivers and API on the embedded OS.

Viewing the entire FPGA as dynamic hardware using a specialized OS that can select from a large library of hardware functions, which then can be loaded in a similar manner to software DLLs.

One disadvantage of FPGA implementations is the relatively long compile time through the design software. Each of these implementations in the FPGA would have to be precompiled through the FPGA software. In addition, a system that can manage the complexity of the hardware design process for the architecture described is needed.