• No results found

Finally we consider the preservation of state during reconfiguration. The state in a device’s flip flops and memories is lost if a global reset is initiated. Current Altera FPGAs only allow full reconfiguration involving a reset and hence, cannot preserve any state.

Current Xilinx FPGAs can be reconfigured without a global reset. This is an important precondition for creating designs with module-based reconfiguration where a part of the design remains operational during reconfiguration. In Xilinx Virtex families, the state in flip flops will be preserved even if they are located in a region that is being reconfigured.

This can be used for self-repair through configuration scrubbing: overwriting the FPGA with the same configuration will not affect processing in the device [122]. State in block RAMs (BRAMs) can be changed through reconfiguration. This can be used as a feature if required, or BRAMs can be skipped during reconfiguration to preserve their state.

2.4 Configuration controller

A reconfigurable system usually consists of a reconfigurable FPGA, a configuration repos-itory and a configuration controller that loads configurations from the reposrepos-itory into the FPGA. In its simplest form, a configuration controller can be a state machine that streams configuration data from memory into the FPGA’s configuration interface. However, configuration controllers are often more complex.

Shirazi et al. introduce a basic concept that consists of a loader and a monitor [96]. The loader detects requirements for reconfiguration and maintains information about the system status. If reconfiguration is required, it instructs the loader to read configuration data from the repository and load it into the device. The separation between monitor and loader is only formal and does not mean that these components have to be implemented separately.

Robinson et al. present an advanced configuration controller scheme [87]. The controller includes a scheduler, pre-emption interface and layout transformer. The scheduler collects configuration requests and processes these into an output queue depending on their priority.

Task pre-emption allows low-level tasks to be pre-empted by higher priority ones. The layout transformer can modify the configuration data in order to write a configuration to a different target location. Brebner et al. present a configuration controller and management system that is located on the FPGA itself [18]. The controller allows flexible allocation of modules with various sizes to current free space. It can also perform defragmentation by relocating modules. Diessel et al. consider a two-dimensional dynamic scheduling and

2.4. Configuration controller 22

Figure 2.7: Structure of a typical reconfigurable system including configuration controller.

placement problem that would arise from being able to freely place a reconfigurable module anywhere inside the FPGA. In a similar approach, Platzner et al. analyse one-dimensional and two-dimensional scheduling and placement problems that the configuration controller has to manage [29]. The controller is implemented on a host CPU that manages the FPGA.

Huebner et al. propose to use configuration compression and add a decompressor module to the configuration controller [48].

Figure 2.7 shows the structure of a reconfiguration controller in a typical reconfigurable system. This illustration is conceptual and does not mean that these components have to be physically separate. Configuration can be initiated by inputs or outputs of the application, or by a direct request from the application. The controller can then perform several tasks such as checking if reconfiguration is possible, scheduling the reconfiguration, allocating a module to a free location, stalling the application and starting of the configuration process. The configuration process itself can involve retrieving configuration data from the repository, decompression of configuration data, modification or retargeting configuration data and finally loading the data into the configuration interface. The controller can make use of a device driver or device API. The following list shows tasks that a configuration controller may have to perform:

ˆ Handshaking with the application. A module under reconfiguration cannot perform any computation and its outputs are unknown. To handle this situation the controller can disable the module outputs, stall the application or instruct the application to buffer incoming data.

2.4. Configuration controller 23

ˆ Compilation of configuration data. If it is impossible or impractical to pre-compile and store all possible configurations, the controller needs to compile configuration data.

ˆ Configuration scheduling. If configuration requests cannot be executed directly without conflict the controller has to schedule configurations based on their priority.

ˆ Placement of modules. The controller may need to place reconfigurable modules on the FPGA. Placement can be fully flexible or limited to pre-defined reconfigurable regions (see section 2.8).

ˆ Defragmentation. Fully flexible placement can cause fragmentation of the device.

ˆ Transformation of configuration data. Relocation and flexible placement of reconfig-urable modules can require a transformation of the address field or of the configuration itself.

ˆ Decompression of configuration data. If compression is used to reduce the size of the configuration storage then the configuration must be decompressed before loading it into the FPGA.

ˆ Context save and restore. If a module is pre-empted then its state has to be saved and later restored to continue execution.

A configuration controller can be an external or internal component. External configu-ration controllers are usually used in systems where the FPGA is a component within a larger host system [71]. An external controller is also required for devices that only support full reconfiguration. Devices with partial reconfiguration can make use of an integrated configuration controller. This makes it possible to create a self-modifying system with an FPGA as the only processing component. For example, McGregor et al. demonstrate the concept of an integrated controller and show that such a system would need non-volatile memory for configuration storage as the only external component [74]. Donlin proposes a reconfigurable processor where the configuration memory is mapped into the processor memory space [31]. Thus, the processor can modify itself in the same manner it accesses application data. This concept demonstrates that the boundaries between reconfiguration controller and reconfigurable application can be blurred or completely removed. Early reconfigurable research was often concerned with converting non-reconfigurable designs into reconfigurable ones and creating the necessary infrastructure. A modern approach,