Managing Reconfigurable Instructions The end of Denard scaling has brought with it the end of performance improvements using traditional microprocess

One approach to addressing this problem
is multi-core scaling, an approach neither absent of challenges
nor expected to continue to help indefinitely.
ASICs, which remove many of the overheads of traditional microprocessor
design, are another promising approach. However, thus far, ASIC-based
accelerators exist only in specific domains, for example in NICs
computing packet check sequences or in FPGAs performing
simple math operations. The problem here is threefold:
1. Selection of effective accelerators is challenging.
2. Once hardened, an ASIC cannot be changed --- this compacts
the difficulties above.
3. Accelerators cannot all be close to the CPU, meaning
that communication costs can be high.

Reconfigurable hardware addresses these concerns.
CGRAs are one approach to maintaining the performance benefits of ASICs
and the flexibility of FPGAs. Selection of suitable hard-blocks is still a challenge,
and mapping existing programs to CGRAs is difficult.
The space of hardware accelerators is far greater than existing CGRAs,
but more compiler work is needed
to support CGRAs with a variety of hardware. Existing commercial
solutions, such as the Merlin compiler focus largely on
offloading computation to FPGAs and support a limited number of
fixed CGRA architectures. LegUp fulfills a similar
role, but targeting FPGAs. DSLs are also a typical way to program CGRAs but come
with steep learning curves and typically apply to a small number
of CGRAs. Existing techniques for mapping to devices with
hard-blocks focus largely on fixed functionality
devices. I propose targeting CGRAs
from legacy code in the same way that these works target
fixed-function accelerators. More broadly, my work
will provide understanding about the tradeoffs between the broad
applicability of finely reconfigurable designs and the efficiency
of ASICs.

An obvious question is: what is the best architecture to target?
One approach to this question is: given some fixed-function ASIC, how can the
coverage of the accelerator be extended to a number of applications by introducing some
reconfigurability? The compiler
plays a key role in answering this question, because the problem of offloading functionality
from multiple applications becomes a task of mapping different applications to
accelerators that differ very slightly.
But this is a chicken-and-egg problem: we need a technique to move from an
ASIC accelerator to an accelerator with a small amount of reconfigurability but much
broader applicability before the appropriate compiler techniques can be
developed. But without the compiler techniques, the potential accelerator
coverage benefits will be unknown.

I propose the development of a tool that will address this problem. Given an
ASIC with an associated functional description and a set of applications, it will
find a reconfigurable accelerator with an appropriate amount of reconfigurability.

There are several phases to this project:
1. Identify a suitable functional description that captures
both accelerator behaviour, and suitable opportunities for
reconfigurability.

There are a few languages that can be used to describe CGRAs
that should also be used as a starting point, Toronto's
CGRA-ME, Tubingen's CGADL and U Washington's SPR.

This step largely requires thinking about
what kinds of reconfigurability make sense, and
understanding a few higher level description
languages.
Basically, I see this part as the ``get a human
intuition for what I want to do''.
2. Find an efficient way to match this flexible accelerator
to code to a code-base in a way where we minimise flexibility
while maximising coverage.

The idea of this one is to output a description with the ``right'' level
of flexibility.
3. The last part is a pass that can match the partially-reconfigurable
accelerator to some new code.