Lecture Notes in Computer Science 4917

COFFEE: COmpiler Framework for Energy-Aware Exploration 199
executed by each slot (this depends on the functional units in that particular slot) can
be specified in the XML machine description. New functional units can be added to the
architecture, compiler and simulator easily by modifying the machine description and
adding the behavior of the new instruction (in C) to the intrinsic library. The framework
provides a user-friendly XML schema to add new functional units and specify
its properties. The operation’s latency, operand specification, pipelining, association of
the functional unit to a certain slot, are specified in the XML machine description and
correctly taken into account during simulation. Different datapath widths can be supported:
16-bit, 32-bit, 64-bit, 128-bit. By varying the width and number of slots, the
trade off between ILP and DLP can be explored. The width can be specified for each
FU separately, allowing the usage of SIMD and scalar units in one architecture. An example
of this approach is shown for ARM’s Cortex A8 in Section 5. SIMD units can
be exploited by using intrinsics, similar to those available in Intel’s SSE2, Freescale’s
Altivec. We have also used the proposed tools so simulate other novel architectures like
SyncPro [13].
The pipeline depth of the processor can be specified in the machine description and
the compiler correctly schedules operations onto pipelined functional units. Based on
the activity, the energy consumption of the pipeline registers is automatically estimated.
This is crucial for architectures with deep pipelines (high clock frequency), and for wide
SIMD architectures. In both cases the number of pipeline registers is large and accounts
for a large amount of the energy cost and performance.
Register File. Register Files are known to be one of the most power consuming parts
of the processor. Hence it is important to ensure that the register file design space is
explored properly. The COFFEE flow can handle centralized register files, clustered register
files, with or without a bypass network between the functional units and the register
files. The size, number of ports and connectivity of the register files are specified in the
machine description file.
Figure 3 shows different register file configurations that are supported by our framework.
Combinations of the configurations shown in Figure 3 are supported, both in the
simulator and the register allocation phase of the compiler. Separate register files for
scalar and vector slots can be used together with heterogeneous datapath widths. An
example of such a scalar and vector register file is shown in section 5 using ARM’s
Cortex-A8 core [14]. Communication of data between clusters is supported for various
ways, as shown in Figure 3, ranging from extra copy units to a number of point to point
connections between the clusters. The performance vs. power trade-off (as inter cluster
copy operations take an extra cycle, while increasing the fan-out of register file ports
costs energy in interconnections) can be explored using our framework.
A detailed study of register file configurations and the impact on power and performance
has been done in [15,16], but these studies are limited to the register file and do
not provide a framework for exploring other parts of the processor.
3.3 Loop Transformations
Having an automated transformation framework integrated to the backend compiler is
crucial for efficient optimization. The URUK framework [6] performs designer directed