FPGA configuration capabilities allow a great flexibility in hardware design and, as a consequence, they make it possible to create a vast number of different reconfigurable systems. These can vary from systems composed of custom boards with FPGAs, often connected to a standard PC or workstation, to standalone systems including reconfigurable logic and general purpose processors, to System-on-Chip's, completely implemented within a single FPGA mounted on a board, with only few physical components for I/O interfacing. There are different models of reconfiguration, which can be classified according to the following scheme - WHO controls the reconfiguration or, in other words, who is in charge of controlling the reconfiguration process from a runtime perspective. As an example, a software executed on a GPP to decide whether or not to reconfigure the underlying hardware because of runtime conditions. - WHERE the reconfiguration interface is located. With reconfiguration interface I am referring to the element that is responsible for the physical implementation of a reconfiguration process, i.e., in Xilinx FPGA the INTERNAL CONFIGURATION ACCESS PORT, or ICAP, controller. The first subdivision, the WHO and the WHERE, is between external and internal reconfiguration. External reconfiguration, as we know, 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. Internal or self-reconfiguration, on the other hand, is performed completely within the FPGA boundaries. Clearly the integrity of the control circuits must be guaranteed during reconfiguration, so by definition self-reconfiguration is a specialized form of dynamic reconfiguration. It is important to stress that a scenario that can be defined as internal reconfiguration, without any doubts, is only when both the controller AND the reconfiguration interface are placed inside the FPGA. - WHEN the configurations are generated The generation of the configurations, the WHEN, can be done in a completely static way (at design time) by determining all the possible configurations of the system. Each module must be synthesized and all possible connections between modules and the rest of the system must be considered. Other possibilities are run-time placement of pre-synthesized modules, which requires dynamic routing of interconnection signal, or completely dynamic modules generation. This last option is currently impracticable, since it would require run-time synthesis of modules from VHDL code, as an example, or other HW description language, a process requiring prohibitive times in an online environment. In the last few years there is an increasing interest towards a sort of runtime generation/adaptation of the configuration bitstream. Examples of this can be found: . in the definition of Just In Time reconfiguration techniques that may be used to exploit a runtime generation of the necessary reconfiguration bitstreams . in the design of evolvable hardware circuits that may self generate at runtime the next generation of the circuits that have to be used to configure the device . in the micro-reconfiguration scenario where, due to a specific design flow, circuits and the corresponding bitstreams may be adapted at runtime just by changing few bits - WHICH is the granularity of the reconfiguration Reconfiguration can take place at very different granularity levels, the WHICH, depending on the size of the reconfigured area. Two typical approaches are smallbits and module based. The first type consists of modifying a single portion of the design, such as single configurable logic blocks (CLB) or I/O blocks parameters, while the second type involves the modification of a larger FPGA area by creating hardware components (modules) that can be added and removed from the system. Each time a reconfiguration is applied, one or more modules are linked or unlinked from the system. - in WHAT dimension the reconfiguration operates The last property is, the WHAT is the DIMENSION. One can distinguish between two different possibilities: mono-dimensional (1D) and bi-dimensional (2D) reconfigurations. In a 1D reconfiguration the resources affected by the process always span the whole height of the device. In other words, it is impossible to configure one set of resources without having to reconfigure the whole columns they span as well. This reconfiguration scheme is imposed by the architecture of some devices, that were quite used back in the days, such as those in Xilinx Spartan 3 and Virtex II families because the smallest addressable configurable unit in these devices is the frame, a vertical line of resources. On the other hand, a 2D reconfiguration allows the partitioning of the configurable resources in a 2D space, allowing the definition of different reconfigurable regions one on top of the other. The 1D limitation has been overcome starting from Virtex 4 and Virtex 5 FPGA families, which can reconfigure specific portions of the device without affecting the entire columns of corresponding resources. In this way more sophisticated architectures can be designed, exploiting the added dimension to the freedom in the choice of reconfigurable areas.