Summary
Reconfigurable Computing (RC) is an area of computer systems architecture
that studies the use of reconfigurable logic as a computational device
to be used along with other computing structures such as integer ALUs,
memory management units, floating-point multipliers, disk controlers,
and network interfaces. As a practical matter, today RC is usually
built with FPGAs. RC is also known as ``Custom Computing Machines''
(CCMs) or just ``Configurable Computing.'' By reconfigurable logic,
we are talking about programming the hardware at the gate-level
rather than at the machine instruction level. That is, if we want to
add two binary numbers with RC, we configure a set of Configurable Logic
Blocks (CLBs) to perform the appropriate AND/OR/NOT operations and
then configure routing resources to logically connect CLBs into an
``add'' circuit. In a general-purpose microprocessor, we encode the
bits of a machine instruction to represent an ADD. The translation of a
high-level programming language to machine language is called compiling
and resulting machine language is called a binary image. Similarly,
hardware circuits can be expressed in a Hardware Descripton Language
(HDL). The translation to a gates and routing information is called
synthesis and the resulting sequence of bits is called a configuration.
It is related to, but subtly different from, Adaptable/Dynamic Systems
which, as defined by NSF (NSF Workshop on Directions for Systems
Research, 1997) includes programmable engines in memory controllers,
cache controllers, configurable data paths, etc. So Adaptable Systems
are configurable but not necessarily built with FPGAs. In general,
RC are adaptable systems and implies FPGAs.
The Reconfigurable Online Architecture Research (ROAR) Project
is concerned about one particular aspect of RC called Run-Time
Reconfiguration (RTR). Clearly, programming the hardware at the gate
level is much more time consuming and is usually done (with great pains)
long before the application is executed. Also, once the desired circuit
is programmed and the application starts, that circuit is fixed until the
next application reprograms it. RTR reprograms (or adapts) the circuit
multiple times during execution. We make the following distinction
between online and offline RTR. If the configuration is determined
during run-time and the CLBs are programmed (and reprogrammed) during
run-time, then it is an online RTR system. Offline RTR refers to
systems where all of the possible configurations are synthesized a
priori but the CLBs may be programed (and reprogrammed) during execution.
Most research in offline RTR is motivated by efficient use of the
expensive CLB resources. (The CLBs are reusable so offline RTR
allows large configurations to use fewer physical CLBs via a type of
programmer-managed ``virtual CLBs.'' This is akin to program overlays
prior to virtual memory in operating systems.) Online RTR has the same
benefit but the motivation for online RTR is usually improved performance.
Since synthesis is a long, time-consuming process (usually synthesizing
a configuration takes much longer than compiling a binary image), online
RTR may seem like it could not possibly result in higher peformance.
Indeed, with synthesis times commonly taking hours and sometimes days
for big configurations, online RTR would seem completely infeasible.
But, in fact, there are a number of examples of online RTR and the
potential performance gains are enormous.
Thus, the primary objective of the ROAR project is to investigate
and advance online RTR systems. We have a number of ongoing investigations
addressing various issues related to the viability of new
techniques for online RTR. The research projects available range
from semester-long projects to Ph.D. dissertations in length and
include both very practical projects and very theoretical projects.
Projects
People
- Dr. Ron Sass
- Srinivas Reddy Beeravolu
- Ranjesh G Jaganathan
- Shyamnath Harinath
- Krishna Mohan Muriki
- Matt Simpson
- Brian Greskamp
- Brian Leonard
Papers
