The easiest way in which an FPGA can be reconfigured is called COMPLETE. In this case the configuration bitstream, containing the FPGA configuration data, provides information regarding the complete chip and it configures the entire FPGA, that is why this technique is called complete. With this approach there are no particular constraints that have to be taken into account during the reconfiguration action, obviously that does not mean that the designer is allowed to whatever he/she wants only because he/she is using a configuration technique based on a complete-reconfiguration. In fact, if two different bitstreams implement two functionalities that have to work one after the other, exploiting the resources of the same chip, the designer has to take into account where to store the data between these two configurations. The simplicity, in some sense, that we are gaining while using a complete reconfiguration is coming at a cost. The main disadvantage of an approach based on the complete reconfiguration technique is the overhead introduced into the computation by the reconfiguration and the fact that there is no way, while working with a single device, to hide even just a portion of this reconfiguration time. In order to cope with this situation a PARTIAL RECONFIGURATION approach has been proposed. Partial reconfiguration is useful for applications that require the load of different designs into the same area of the device or the flexibility to change portions of a design without having to either reset or completely reconfigure the entire device. For current FPGA devices, data is loaded on a column-basis, with the smallest load unit being a configuration bitstream frame, which varies in size based on the target device. Partial reconfiguration of Virtex devices, or simply partial reconfiguration, is based on the idea that instead of resetting the device and performing a complete reconfiguration, new data is loaded to reconfigure a specific area of the device, while the rest of the device will not be touched. Using an approach based on partial reconfiguration, the basic idea is to partition the overall input system in a set of functionalities: f1, f2, . . . , f4, as it is in our example where different functionality has been represented by resources coloured using different colours, able to produce a set of bitstreams, b1, b2, . . . , b4 that are not used to reconfigure the entire system but just a known portion of it. In our example we can observe the partial reconfiguration of just one of our functionalities expressed by the changing from green to purple. Obviously, within this context, we are also looking for a sort of “bootstrap” bitstream which is a complete bitstream used to start, to bootstrap, our system. But this complete bitstream, the other functionalities are downloaded to reconfigure just portions of the architecture and because of this we may refer to these bitstreams as partial reconfigurable bitstreams. Up to now reconfiguration has been defined from the area prospective, but there is one more important factor that can be used to classify a reconfigurable approach: the location of the controller of the reconfiguration. EXTERNAL RECONFIGURATION implies that an active array may be partially reconfigured by an external device such as a Personal Computer, while ensuring the correct operation of those active circuits that are not being changed. On the other hand, INTERNAL or EMBEDDED RECONFIGURATION assumes that specific circuits on the array are used to control the reconfiguration of other parts of the device. In this specific context we are going to refer to these circuits with the terms “manager” but, at the end of the day, this manager is the reconfiguration controller we have already defined. Within this context it is easy to understand that an internal configuration cannot be combined to a complete reconfiguration. If the reconfiguration has to be exploited, managed, by an internal component of the chip, this cannot be entirely configured. Furthermore, it is clear that this kind of reconfiguration it is based, or, maybe better, it extends the concept of partial reconfiguration. Once initially configured, internal or embedded reconfiguration requires an internal reconfiguration interface that can be driven by the logic configured on the array. Within this context we are working with a reconfiguration which is taking place internally. Instead of using an external component to implement the reconfiguration, the reconfiguration controller is placed inside the FPGA itself. Starting with Xilinx Virtex II parts, the reconfiguration interface used in this context is the INTERNAL CONFIGURATION ACCESS PORT, ICAP. These devices can be configured by loading application-specific data into the configuration memory, which is segmented into FRAMES, the smallest unit of reconfiguration. The number of frames and the bits per frame are different for the different devices of Xilinx FPGA families. The number of frames is proportional to the CLB width of the device. We can now introduce the concept of a STATIC RECONFIGURATION. STATIC means that, while the reconfiguration process is taking place, the system is all focused on it and no other computations are taking place. Within this context it is quite easy to understand that a complete reconfiguration is not only external, but also static. If the entire device has to be configured, we need to have an external controller to take care of it and, obviously, we cannot have anything else happening but the reconfiguration process. This is is quite easy to be understood in the complete scenario, but it is something that may happen also in the partial one. As it was happening in the soccer case, while the reconfiguration of a portion of the system is taking place, the other elements cannot continue the execution of their tasks. As we can see from this figure, in our FPGA we have four functionalities represented by the four different colours. While two functionalities are working, the manger will take care, as we know, of the reconfiguration of the third one. Now, within this context we cannot allow the partial reconfiguration of the third functionality to take place, unless the other two are not going to continue with their executions. Once they’ve been placed on hold we can then configure the interested functionally with the new one. At this point, once the partial reconfiguration of the new functionally has been completed we can then proceed in allowing the other two functionalities to continue their execution ... which is exactly the scenario presented in this figure. This scenario is still quite interesting because it is introducing some benefits with respect to the complete reconfiguration case. The reconfiguration overhead introduced by the complete reconfiguration is quite high, while here, it depends only to the dimension of the reconfigurable region which is meant to be reconfigured, therefore we can play with this information to try to design a system which will be able to leverage on this. Still, because of the static scenario we can try to reduce the reconfiguration time but we cannot try to hide it, which is exactly why we are going to introduce a DYNAMIC RECONFIGURATION. With such a scenario the reconfiguration time of a portion of the FPGA is hidden by the computation of the remaining part. In order to be able to hide the reconfiguration time it is not only necessary to partition the FPGA into reconfigurable regions to obtain the ability to compute partial reconfiguration bitstream, but it is also necessary to guarantee that a reconfiguration is not going to imply a stall in the computation of the not-involved logic of the device. Such a scenario brings to the definition of Dynamic Partial Reconfiguration. Within this context we can define DYNAMIC PARTIAL RECONFIGURATION as the ability of a system to configure just certain areas of the device while other areas remain operational and unaffected by the reprogramming, except during some inter-design communication.
