Partial reconfiguration in FPGA rapid prototyping tools

Raúl Torrego, Ikerlan-IK4
Iñaki Val, Ikerlan-IK4
Eñaut Muxika, University of Mondragón
Ander Berrizbeitia, Ikerlan-IK4

Abstract:

FPGA rapid prototyping tools are greatly useful at the time of designing and testing complex signal processing systems, due to their graphic programming environment and the possibility they offer to functionally simulate the whole system before synthesizing the code. Furthermore, FPGA partial reconfiguration is a very effective feature when trying to reduce the resources needed to implement systems dealing with multiple functionalities. Unfortunately, this characteristic is not supported by the rapid prototyping tools. This paper exhibits the state of the art of partial reconfiguration in FPGAs and rapid prototyping tools and shows the way of linking them in a single design.

INTRODUCTION

Programmable devices in general and particularly FPGAs are becoming the alternative to microprocessors and classical architectures in nearly all the new technologies that need high speed data processing, including 3G/4G communication systems, high definition television, medical instrumentation such as 3D echographies or software-defined radios (SDR). This proliferation of FPGAs is caused by a mixture of factors like their low cost, their high processing speed, achievable due to their hardware oriented programming, their reprogrammable nature which makes the development and testing of designs easier and new characteristics such as the partial reconfiguration [1]. This characteristic allows a part of the FPGA to continue working, while other parts of it are being reprogrammed. On one hand, this allows the static part to manage the reconfiguration of other parts, what is called “Partial self -reconfiguration”. On the other hand, this enables an FPGA to carry out different

functionalities without penalizing its size, reusing a specific area each time a functionality change is needed. Another factor responsible for FPGAs spreading all over the market right now, is the level of robustness and reliability they have reached, which generated reticence between hardware designers some time before.

Although the VHDL language used to program the FPGAs is easy as well as very powerful, from the design time saving point of view, it is much more efficient to use rapid prototyping tools when doing the system design. These tools allow to carry out the system design on a graphic environment, using drag and drop, and connecting different blocks that represent the typical functions that appear in the data flow of this kind of systems. Afterwards VHDL code that is synthesizable for the FPGA can be generated. Apart from this advantage of not having to write down the code by hand, the rapid prototyping tools permit the designers to make a functional test of the design without having to execute the code synthesis, usually a time consuming task when talking about complex systems, which in turn leads to huge time savings.

Therefore being able to combine the benefits of the partial reconfiguration with the use of rapid prototyping tools is very interesting. This is what this paper considers because it is not supported in the standard design flow.

FPGAS AND PARTIAL RECONFIGURATION

FPGAs (Field Programmable Gate Arrays) are programmable logic devices that can implement any type of digital circuit, from the simplest logic gate, to the most complex SoC (System on Chip) made up of several processors with their respective peripherals. This if possible due to the particular structure FPGAs have (Figure 1), made up of an interconnection matrix which communicates thousands of CLBs (Configurable Logic Block). These blocks constitute the heart of the FPGA and are typically formed by a combinational programmable circuit LUT (Look-Up Table), a bistable, additional logic and SRAM memory cells where the configuration information of the rest of components is stored [2]. Apart from these basic elements, FPGAs provide dedicated input-output blocks (IOB), as well as some extra resources, implemented in silicon, and wired to the interconnection net. These resources depend on the FPGA family and have contributed to the increase of the FPGA utilization last years, as they provide FPGAs with dedicated elements such as multipliers, RAM memory, communication controllers and even microprocessors, all of them having a great performance as they are integrated inside the FPGA.

Figure 1: Generic diagram of an FPGA

Paying attention to the CLB structure again, SRAM configuration memory stores the configuration of the rest of components in the CLB, so a change in the data of this memory directly changes the functionality of the CLB. In this characteristic lies the possibility of partially reconfiguring the FPGAs. Rewriting only specific memories, it is possible to change the functionality of parts of the FPGA while others remain unchanged. However, it must be said that only SRAM technology based FPGAs support it, not being possible to partially reconfigure Anti-fuse, or FLASH technology based FPGAs. The fist ones are programmed through physical melting of conducting fuses so once programmed their configuration cannot be changed. Meanwhile, FLASH based FPGAs’ reconfiguration, although technologically supported as configuration is stored in memories, nowadays is not offered by FPGA manufacturers.

Briefly, two kind of partial reconfiguration exist, difference based and module based ones [3]. In the first case, the functionality changes of the CLBs are minimum, being reduced to changes in the equations stored in the LUTs, changes in the data stored in the Block RAMs, changes in the input-output standards... etc. Therefore, the way of proceeding is comparing two designs and extracting the differences between them, being these differences the ones that are lately rewritten in the configuration memory. On the other hand, in the module based partial reconfiguration, the whole functionality of a group of CLBs is changed, so the design flow changes meaningfully. This second option is the one used when a complete change in a part of the FPGA is wanted; therefore, it is the most interesting from the point of view of the objectives this paper wants to achieve.

RAPID PROTOTYPING TOOLS

Rapid prototyping tools, in general, are programs situated at a higher level than the code compilers/synthesizers. They add them functionalities that improve or ease the code design such as functional simulations that get results early in the design flow, graphic programming environments or cosimulation. Under this description very different types of tools can be included, from Visual Basic or SystemC, through Matlab/Simulink, to System Generator, CatapultC or SystemVue.   

Focusing on the tools specially designed to work with FPGAs, they usually have a graphic interface so that programming is made interconnecting available predefined blocks. These blocks usually represent functions or components that are typically used in signal processing or in the digital logic world, from logic gates to multiplexers, filters or microprocessors. This way, programming is very intuitive and the signals that connect the different blocks represent the real, physical, data paths. Once a design is finished, these tools are able to generate the VHDL code that describes the system, synthesize it, and even, upload it directly to the FPGA. Furthermore, many of these tools work under the Matlab/Simulink environment, so before executing this synthesis and upload, it is possible to carry out a functional simulation, making available, for the results’ analysis all the resources this environment offers, like scopes, customizable data sources or spectrum analyzers.

On the course of the preparation of this paper, the analysis of two different tools has been made, on the one hand to make use of all the advantages each tool offers, and on the other hand to demonstrate that it is possible to integrate both on a single design. These two tools are System Generator by Xilinx [4] and Codesimulink/SMT6040 by Sundance [5]. Both tools have similar graphic interfaces and work flows, based on predefined blocks as it has been explained before. The biggest difference between them is the fact that System Generator is a generic tool for generating code for any Xilinx FPGA, while Codesimulink/SMT6040 is oriented towards working with Sundance development boards. Therefore, Codesimulink/SMT6040 provides specific blocks to manage the particular subsystems Sundance introduces on its boards, like clock generating chips, A/D and D/A converters or communication buses (Figure 2 and Figure 3). Additionally, when working with some concrete boards, Codesimulink/SMT6040 allows the designer to synthesize the design in a hybrid hardware/software way, “translating” parts of the system into C++ and executing them in a DSP while the rest remains in the FPGA.

Figure 2: Design in System Generator

 Figure 3: Design in Codesimulink/SMT6040

Analyzing the nature of the generated VHDL code; both System Generator and Codesimulink/SMT6040 include a high level specification system that allows the design of “Data Flow” type of architectures where different blocks intercommunicate. In addition, in System Generator, it is possible to design control oriented systems with the “Black box” named blocks, which define its functionality via user introduced VHDL code. This minor difference has no influence when intending to apply partial reconfiguration to the generated code, since the top hierarchy entities generated in both tools, the ones containing the whole design, share mainly the same out-world communications. In both cases the top VHDL entities have input-output data ports, a clock signal and other auxiliary signals such as enables or resets, what makes partial reconfiguration possible as will be seen later

USE OF PARTIAL RECONFIGURATION ON DESIGNS GENERATED WITH RAPID PROTOTYPING TOOLS

Rapid prototyping tools are able to generate the bitstream that configures the FPGA and even upload it, but in order to integrate its use with the partial reconfiguration, the starting point is the generated VHDL code. This code has to be integrated into the partial reconfiguration flow using the classical EDA (Electronic Design Automation) tools like Xilinx’s ISE. This design flow is based on a “top” design written in VHDL, where, in a model based method, all parts of the design must be instantiated, both the static parts (named “Base” in Figure 4) and the reconfigurable ones (named “PRM” – Partial Reconfiguration Module). There are some restrictions this high level project has to meet, which are perfectly explained in Xilinx’s official documentation [6]. Among them, three are really important when integrating systems designed with rapid prototyping tools: maintaining the concordance between the name and ports of the reconfigurable instances, managing those instances’ clocks and using correctly the so called “Bus macros” when communicating the static and reconfigurable worlds (“BM” in Figure 4).

Figure 4: “Top” project detail

In the “top” project a unique reconfigurable module is instantiated. Later, as the design flow goes on, the entities that describe all the possible functionalities for this reconfigurable module are linked to it. Consequently it is compulsory that every entity has the same name and the same connections the ones the reconfigurable module instantiated in the “top” project has. This makes it necessary to create a wrapper file for each design generated with the rapid prototyping tools, where each design is instantiated and the entity name and signal towards the external world are homogenized. Any kind of adaptation must be done inside this file. In short, no matter where the different projects that describe the functionality of the reconfigurable module come from, in the end all of them must be treated so that their name and external connections match up with the instantiation done in the “top” project.  

The second condition that must be met concerns the components that can or cannot be reconfigured. Clock management resources such as DCMs (Digital Clock Manager) or BUFGs (Global Buffer) are not reconfigurable, so they can not be part of a reconfigurable module. In case they must be used, they have to be placed in the “top” project. Taking into account VHDL code is automatically generated by the rapid prototyping tools, it is necessary to look through the synthesis information they offer and check if any of these components have been included in the design. If so, they must be either deleted, or, if this is not possible due to timing problems, moved to the “top” project.

Finally it is necessary to look for all the possible connections between the static and reconfigurable parts. In each of these connections it is obligatory to instantiate in the “top” project the so called “Bus macros”. These components fix the signal routing between the static and reconfigurable parts and act as high impedance while the reconfiguration process is going on. As the rewriting of the SRAM memories (remember that it is the way an FPGA is reconfigured) is done in a serial way, it could be possible that in a certain moment a internal connection had two drivers attached to it, one in a high level ‘1’ and the other in a low level ‘0’, this, without the use of a bus macro, would end up in the partial or total destruction of the device.

Once these conditions are correctly met, the standard partial reconfiguration flow would continue with the use of the Plan Ahead software. This program takes the “top” project and all its related files and, after processing them, generates the static bitstream and the partial ones [7].

CONCLUSION

Both, the use of rapid prototyping tools and partial reconfiguration, offer great benefits and advantages when designing complex systems, however, using them together in a design is not still a standardized procedure. The steps that need to be followed for achieving it are not very difficult, but require quite a bit of knowledge of the used tools and of the requirements the partial reconfiguration needs in order to everything work correctly and no risk for the device is assumed. Furthermore, this paper has only considered the necessary steps for implementing a partial reconfigurable system designed with rapid prototyping tools, leaving the integration of the partial reconfiguration behaviour in simulation for a future work.

ACKNOWLEDGEMENT

This work was supported in part by the Strategic Research Project program of the Government of the Basque County (Spain), through the project TEReTRANS, Expt: IE8-221.

REFERENCES

[1]    C. Kao, “Benefits of Partial Reconfiguration” Xcell Journal. Fourth Quarter 2005

[2]    A. Astarloa, “Reconfiguración dinámica de sistemas modulares multi-procesador en dispositivos SoPC” Unpublished Doctoral Thesis, Universidad del Pais Vasco, July 2005.

[3]    Xilinx XAPP290, “Two flows for partial reconfiguration: module based or difference based” September 2004.

[4]    Xilinx, “System Generator for DSP User Guide” Release 10.1.1. April 2008

[5]    Sundance, “SMT6040 Sundance Simulink Toolbox” June 2009

[6]    Xilinx UG208, “Early Access Partial Reconfiguration User Guide For ISE 9.2.04i” September 2008.

[7]    Xilinx, “Partial Reconfiguration Design with PlanAhead” March 2008.