A computational grid may take a variety of forms, from a
simple stand-alone collection of but a handful of identical
processors, to vast networks with many types of compute
engines. It can facilitate collaboration and data sharing.
It can be used to capture cycles that would otherwise be
wasted. In many high-performance applications, its inherent
parallelism can even obviate the need for expensive supercomputers.
Reconfigurable hardware offers a means for combining
the performance of custom IC design with the flexibility
of software. Its most critical feature is the reconfigurable
processing element which, in the current generation,
is a Field-Programmable Gate Array (FPGA) chip. Because
these elements can be dynamically reconfigured to
implement application-specific computations, one can often
achieve orders of magnitude improvements in price and
performance over conventional processors for a variety of
applications.
Both grid and reconfigurable computing are rapidly
gaining in popularity. We are keenly interested in novel applications
that can exploit the synergies of these two rather
complementary technologies. A central goal is to provide
grid-accessible solutions to diverse communities of scientists.
Researchers having only desktop access to the grid
can thus solve large computational problems, many of them
once considered beyond reach, by calling on wide-area distributed
computing resources and advanced hardware platforms.
Although much progress has been made in hardware speed,
cost and efficiency, the concomitant need for software support
has not been well satisfied. Yet such support is sorely
required if the user need no longer be a CAD expert to benefit
from acceleration via reconfigurable hardware. To meet
this requirement, we have employed the NetSolve middleware
as an interface to ease the use of FPGAs. In particular,
we have adopted one of NetSolve’s resource sharing
mechanisms, the Problem Description File (PDF). A PDF
is a means for itemizing the relevant I/O specifications, libraries
and so forth needed to pass parameters and execute
programs on a particular grid element.
|
We illustrate the utility of the PDF with an example,
the Fast Fourier Transform (FFT). Our GSC, like many
others, has in residence efficient software versions of the
FFT. These are easy to install, and generally written in C
or FORTRAN. Once compiled, they are of course run on
a CPU. Unlike other GSCs, however, we also have in residence
an accelerated version of the FFT that uses FPGAs
to speed the computation. Installing the accelerated version
requires a bit more effort. First, code written in VHDL or
some other hardware description language is needed. This
code then goes through a synthesis process, whereby the
application is mapped onto the FPGA hardware. The result
is a configuration file that, when loaded onto the FPGA, de-
fines how its CLBs should be set so that the desired functionality
is realized.
Users with accounts inside our GSC may of course
access either FFT without the aid of NetSolve. Suppose
now that a user elsewhere wishes to determine what gain if
any is achievable by executing a hardware FFT. As SInRG
is currently configured, our GSC is the grid’s only computational
resource with the ability to satisfy the user’s need.
The user may not necessarily know this, naturally, but by
what process can he or she seamlessly take advantage of
our reconfigurable implementation? We have resolved this
question by providing NetSolve with two PDFs, one for a
software FFT, and one for a hardware FFT. Thus, when a
remote user requests an FFT from NetSolve, one of two
actions is taken. If the request specifies a software FFT,
then NetSolve searches the grid for an available computational
node that is appropriately configured, that is, one
with a resident software FFT whose PDF has already been
furnished to NetSolve. This element may be in our GSC
or elsewhere. By the same token, if the request specifies an
accelerated FFT, then NetSolve has the information in hand
to determine that under current conditions our GSC is the
only site of choice. Accordingly, NetSolve will select our
GSC and direct that we run the hardware implementation
for the user.
|