Applications
High-Performance Computational Grids with NetSolve

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.

A Grid Service Cluster with Reconfigurable Hardware

A Grid Service Cluster with Reconfigurable Hardware

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.

Researcher: Michael A. Langston ( langston@cs.utk.edu )
Institution: University of Tennessee - Computer Science

Related Work

 


Additional Applications

 
 

  Innovative Computing Laboratory
 
Contact NetSolve: netsolve@cs.utk.edu Computer Science Department
  University of Tennessee