FONT SIZE : AAA
The concept of FPGA reconfiguration is, in essence, very simple: By just rewriting the contents of the configuration memory, the functionality of the device may be modified. This would provide the same flexibility as software does, but the reality is far from being that simple. Currently, there is not enough support—in terms of tools and standardization—to easily design reconfigurable systems. There is no sufficient support from the vendors to seamlessly integrate reconfiguration into the design flows either. Support is slowly being provided by academic efforts in applying reconfiguration for specific purposes, but not in a generic way.
The first FPGA devices could only be (re)configured by downloading into them a full bitstream, which would overwrite all configuration bits in the device. The configuration had to be static and performed immediately after system power-up. However, an increasing number of FPGAs, in par- ticular those based on SRAM technology, are now allowing the so-called partial bitstreams to be downloaded, so reconfiguration can be applied just to some portions of the device (what is referred to as partial reconfigura- tion), even while the rest of it keeps working normally (a feature called run-time- reconfiguration, RTR). Systems having this last feature are said to be run-time reconfigurable systems (RTRSs), and those having both are called partial run-time-reconfigurable systems (PRTRSs).
Partial reconfiguration is a valuable feature for systems operating in envi- ronments where applications cannot be interrupted while the system is being reconfigured. It is also suitable for highly parallel systems that can time-share the same FPGA resources. Without this capability, it would be necessary to stop system operation during device reconfiguration and to reconfigure the entire FPGA to support a different application.
A special subset within RTRSs is composed of systems that can reconfigure themselves, which are referred to as self-reconfigurable systems (SRSs). The availability of internal configuration ports, embedded in the logic fabric, such as the Internal Configuration Access Port (ICAP) or the Processor Configuration Access Port (PCAP; managed from an embedded hard pro- cessor as in the case of Zynq devices, discussed in Section 3.3), allows self-reconfiguration to be easily carried out. Being a specialized hardware block within the silicon, PCAP has two main advantages over ICAP: It is available and ready to be used at any time (even at boot time, because it does not need to be configured in the FPGA fabric), and there is no risk of overwriting the logic that interfaces with the configuration logic.
Flash memory-based FPGAs are also capable of achieving both full and partial reconfigurations. However, care must be taken with the number of reconfigurations since flash memory contents cannot be rewritten too many times. For instance, while flash memories may usually support 10,000–100,000 programming cycles; this figure is reduced to around 1,000 times for space- qualified devices.
Applications requiring extensive reconfiguration should only be imple- mented in SRAM-based FPGAs. Consider a low Earth orbit satellite for marine observation, with several orbits per day, which is reconfigured for image acquisition, processing, and identification while over the sea and reconfigured again when over a reception station for data compression, encryption, and transmission. A flash-based device could not be used for more than a few months. With ASIC or nonreconfigurable technologies, both groups of functionalities would be required to be permanently implemented in the silicon. These problems can be overcome by using reconfigurable technology.
SRAM-based technologies are, however, susceptible to suffer SEUs (i.e., bit-flips) not only in the application logic but also in the configuration logic. Therefore, in some applications, ECCs, modular redundancy, and other tech- niques must be used in order to minimize this problem. Some of these can take advantage of reconfiguration capabilities, as discussed in Sections 8.4.1 and 8.4.3.
Granularity is another important aspect in partial reconfiguration, related to the size of the functional elements that are reconfigured, both regarding the reconfiguration needs of the application and the reconfiguration capa- bilities of the devices:
• Large granularity corresponds to systems where complex IP cores are replaced in the logic and, therefore, partial reconfiguration affects large portions of the FPGA. There are devices where partial reconfiguration can only be applied to a significant part of the FPGA (e.g., one half), or others that use an approach based on slots, where the FPGA is divided into several, normally identical, slots, each of which can be reconfigured separately.
• Medium granularity corresponds to reconfiguration at register level, which is typically used to modify functionality in a portion of an IP core.
• Small granularity refers to the reconfiguration of a small number of configuration bits, typically affecting the values stored in an LUT, the content of a flip-flop, or resources of similar complexity.
For large and medium grain, reconfigurable regions (RRs) must be defined such that different reconfigurable modules (RMs) may be allocated into them. If a given RM is compatible with—may be allocated into—more than one RR, then the RM is said to be relocatable. Relocation procedures are available in the reconfiguration engines to address the corresponding RM configuration information into the part of the configuration memory corresponding to the target RR in each case.
Module relocation is a clear advantage in systems based on regular slots since the same function may be allocated into different regions, providing additional flexibility, a certain degree of fault tolerance (a function may be moved from a faulty to a fault-free region), and memory footprint savings, since just one bitstream is required to support all destinations, instead of one for each possible destination.
One of the major problems associated to partial reconfiguration is how to match the required reconfiguration granularity with that actually sup- ported by the FPGA technology being used. The smallest reconfigurable area in FPGAs depends on the manufacturer (manufacturing technology and family of devices). Some FPGA families support column reconfigura- tion; that is, the minimum reconfigurable unit is a column of LBs (defined in Section 2.2). The problem with this solution is that when something has to be changed even in just a single element, the entire column has to be reconfigured. More recent families support rectangular reconfiguration, where the portion being reconfigured does not necessarily have to span a whole column.
The main benefits of disruptive—non-real-time—partial reconfiguration are reduced configuration times and the possibility of silicon reuse, since the same device can be used for different tasks. In addition to these, the added benefits of using PRTRSs can be briefly summarized as follows:
• Enhanced performance and system updates because, while por- tions of the system are being reconfigured, the rest can remain operative. Hence, there is no loss of performance in the areas not being reconfigured, at least in principle (it may be in those interact- ing with parts being reconfigured). Also, system updates would in principle only affect the areas where the updated functionality is being configured.
• Hardware sharing, because in addition to the possibility offered by full reconfiguration for several applications to share the same FPGA (reducing size and cost), in this case, these applications can be exe- cuted in parallel. This characteristic is gaining importance with the increasing integration level of FPGA devices.
• Shorter reconfiguration time and lower reconfiguration energy consumption, because partial reconfiguration requires smaller (partial) configuration bitstreams than full-device reconfiguration. In this regard, it has to be noted that techniques that accelerate the reconfiguration process at the expense of increasing instantaneous power consumption usually result in overall energy savings.
• Reduced requirements for bitstream storage resources.
RTR has also some associated problems. Even though some FPGA vendors claim they use suitable techniques so that run-time reconfiguring in their devices in an area with the same configuration it had before is a glitch-less operation, there are many restrictions derived from the atomic reconfigura- tion unit that can be handled. For instance, if the content of a flip-flop has to be modified, all flip-flop contents in the same column for a column-based recon- figurable FPGA have to be modified. In order to do this, system execution has to be stopped, a read-back operation has to be carried out to retrieve the con- tents of all flip-flops in the same column, then the desired flip-flop value has to be modified, and all flip-flops in the column have to be configured back. This does not allow real RTR to be achieved, whereas if the atomic reconfigu- ration unit were a single flip-flop, it would have been possible.
There are many reconfigurable system models, most of them relying on the use of microprocessors and reconfigurable fabric. According to Al-Hashimi (2006) and Compton and Hauck (2002), there are several possible types of coupling between both parts, as shown in Figure 8.1:
• External stand-alone, where the reconfigurable hardware is a fully independent device connected to the inputs and outputs of the microprocessor.
• Coprocessor unit or attached processor unit, where the reconfigurable hardware is closer to the microprocessor than in the previous case.
FIGURE 8.1Different integration levels of reconfigurable logic within a processor system.
In the coprocessor approach, the reconfigurable hardware can operate as a functional resource of the microprocessor itself. In the attached processor solution, the reconfigurable hardware is accessed after the cache memories, that is, in the secondary bus.
• Reconfigurable functional unit (FU), where the reconfigurable hard- ware is embedded into the microprocessor. This structure is the one that most easily allows custom instructions to be added to the processor.
• Processor embedded in the reconfigurable hardware. In this case, the processor may be either soft (analyzed in Section 3.2) or hard (analyzed in Section 3.3).
Manufacturer:Xilinx
Product Categories: CPLDs
Lifecycle:Active Active
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: Contrôleur logique
Lifecycle:Obsolete -
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: Programmable logic array
Lifecycle:Any -
RoHS: -
Manufacturer:Xilinx
Product Categories: Programmable logic array
Lifecycle:Any -
RoHS: -
Manufacturer:Xilinx
Product Categories:
Lifecycle:Obsolete -
RoHS: No RoHS
Support