Design methods for reconfigurable systems can be done at different abstraction lev-els. In a software-like approach, the hardware task is described in a language bor-rowed from the software world, e.g. C/C++, or in application specific languages like Matlab/Simulink and SA-C [14]. The C-language derivatives often have special intrinsics to describe hardware-like behaviour. In a hardware design approach, cir-cuit function is described in a hardware description language, i.e. VHDL or Verilog.
The pros and cons of both approaches will be discussed at the end of the section. At first we will introduce both concepts in detail.
2.3. Methods for Design Entry 25
2.3.1 Behavioural Design Entry
The design entry is usually with done in a high level language. Popular examples are the ANSI-C derivatives Handel-C [1], Streams-C [33] and CatapultC [59]. The languages do not conform to a common standard, they are specific to the related design tools and libraries. Often, they are also specific to an architecture [8]. The languages provide macros to support special hardware related constructs, e.g. ac-cess to i/o-ports, extensions to describe parallelism in parallel loops, and timing with cycle constraints.
The tools offer some control over the compilation process that allows the de-signer to constrain design performance and resource allocation. After compilation, the design is represented in an intermediate representation. If the target is a fine grain architecture, then the intermediate representation might be a hardware de-scription language or a target specific netlist. For coarse grain architectures the intermediate representation is closer related to an assembly language. Finally, a device mapper maps the constructs of the intermediate representation to specific resources in the architecture. The configuration data of the device can be directly generated from this mapping.
2.3.2 Design Entry at Register-Transfer Level (RTL)
This design style is very common for FPGA-like architectures. The behaviour of the hardware task is described in a hardware description language. These languages have an inherent model for parallelism and provide access to hardware functions at gate-level.
A synthesis tool compiles the hardware description into a device specific netlist, using target-dependent libraries. The RTL description can be target independent, at least to some extend. The description might contain instances of target-dependent modules to access special functions in the device. However most functionality can be described without those instances.
The compiled netlist is mapped to device resources with a device mapper. The result is a device specific netlist that contains instances of hardware architecture elements with the elements’ configuration and the required connections. The com-pilation process succeeds by binding the elements to actual hardware resources, a step known as placement. A router realizes the connectivity by allocating appropriate wires between hardware resources.
The configuration of the device is fully specified after place and route. The con-figuration needs to be translated to a binary program, called bitstream, that contains the configuration data and the configuration commands for the target device.
Both methods for design entry have distinct advantages. Behavioural design entry allows high productivity in complex designs. Changes in the original speci-fication can be incorporated quickly into an existing implementation. Behavioural
design entry is very tool dependent. RTL design is less flexible and productive, but designers can implement very optimized designs because the HDL allows a detailed description of the implemented architecture. HDL code is portable between vendors because VHDL/Verilog are standardized.
2.3.3 Xilinx Early Access Partial Reconfiguration (EAPR) Design Flow
Xilinx provides design tools and a special design flow specific for partial reconfigu-ration. The design flow is summarized in the following in order to explain available techniques and restrictions for partial reconfiguration that exist in current design tools. For more details refer to [106][108].
The EAPR flow provides guidelines on how to implement partial reconfigurable designs on Xilinx FPGAs. At first, the designer sets up a top level design. The top level design instantiates global resources, i/o-pins and static and partial reconfigurable modules. In addition, a floorplan for the top level design is created which assigns a placement to global resources and to the modules. The placement of the reconfig-urable modules is fixed by this floorplan; they can only be placed freely at runtime with relocation methods [46]. The top level module also contains busmacros that provide a fixed interface between static and reconfigurable modules in the design.
In the next step, the static and reconfigurable modules are designed, verified and prepared for place and route by a synthesis tool.
Now, only the top level design is implemented, i.e. the design is placed and routed without the static or reconfigurable modules. This yields a static, base con-figuration of the device in which the modules will be integrated. Next each module is implemented independently of the other modules on top of the base configuration.
In the merge step, all implemented modules are merged to complete configurations, from which the partial configuration data is generated. The complete configurations are used as initial device configurations and the partial configurations are used to reconfigure the device partially. The merge step produces as many initial and partial configurations as there are reconfigurable modules in the design.
The restrictions of the EAPR design flow clarify that partial reconfiguration in Xilinx devices is targeted at task-based reconfiguration. However, the partial config-uration data can be processed to eliminate redundancy, see Section 2.5. At runtime, only configuration data that differs between configurations must be loaded into the device which allows further optimizations. The aim of the EAPR flow is to produce configuration data valid for partial reconfiguration. It provides predefined mecha-nisms to connect static and reconfigurable circuitry in a design. The reconfigurable modules are implemented independently, i.e similarities between the modules are not exploited in order to produce implementations with less reconfiguration over-head. Also, the design flow is not automated but must be carried out by the user