300 likes | 2.53k Views
On a Grid-Based Interface to a Special-Purpose Hardware Cluster Jeanne Lehrter University of Tennessee May, 2002 Presentation Outline Introduction Background Grid-Based Software Our Work Conclusions Future Work Introduction The need for grid computing SInRG research project
E N D
On a Grid-Based Interface to a Special-Purpose Hardware Cluster Jeanne Lehrter University of Tennessee May, 2002
Presentation Outline • Introduction • Background • Grid-Based Software • Our Work • Conclusions • Future Work
Introduction • The need for grid computing • SInRG research project • NetSolve middleware by ICL • Project Goals
Types of Hardware • General purpose hardware – can implement any function • ASICs – hardware that can implement only a specific application • FPGAs – reconfigurable hardware that can implement any function
FPGAs • FPGAs offer reprogrammability • Allows optimal logic design of each function to be implemented • Hardware implementations offer acceleration over software implementations which are run on general purpose processors
Grid-Based Software • NetSolve middleware • Client-server-agent model • Loosely-coupled heterogeneous environment • No root or superuser privileges are required to run any part of NetSolve
NetSolve Agent • Resource broker • Maintains database of server characteristics and usage statistics • Runs on Linux and UNIX
NetSolve Client • Provides access to remote resources • Interactive and programming interfaces • NetSolve tools available to client • Runs on Linux, UNIX, and Windows
NetSolve Server • Offers resources to remote users • Expandable capability • Requires problem description file (PDF) for new functions to be added • Contains a source code generator that creates service functions
Cluster for Advanced Machine Design • Grid service cluster (GSC) in ECE • Eleven SUN 220R Dual 450MHz UltraSPARC II processors running Solaris • Eight Pentium III PCs running Linux with Xilinx Virtex-1000 chip attached • A1000 RAID data storage unit • 1 Gbit/s Foundry switch
Pilchard Environment for the FPGAs • Developed at Chinese University in Hong Kong • Plugs into 133MHz RAM DIMM slot and is an example of “programmable active memory” • Pilchard is accessed through memory read/write operations • Offers higher bandwidth and lower latency than other environments in which FPGA is placed in a PCI slot
Server Software Requirements • NetSolve server software (and all software that is required by the NetSolve software, eg C compiler) • Library of functions to be offered by the server • PDFs that define the interfaces to these functions
Extra Software Requirements for ECE GSC • Two types of functions are implemented in the ECE GSC • Software version - runs on the PC’s processor • Hardware version - runs in the FPGA • To implement the hardware version of the function, the software requirement of VHDL code is added
Implementing the Hardware Function • The function is implemented in VHDL (or some other hardware description language) • The VHDL code is then “mapped” onto the FPGA through the synthesis process • Mapping decisions are based on constraints such as: chip area, I/O pin counts, routing resources and topologies, partitioning, resource usage minimization
Implementing the Hardware Function Cont. • Synthesis process transforms the VHDL description of a function to a configuration file which is a bit stream • Configuration file defines how the FPGA is to be reprogrammed in order to implement the new desired functionality • Hardware version of a function will copy the configuration file and function parameters onto the FPGA for processing
Server Example • Consider this function interface to the software implementation of the Fast Fourier Transform: void fft(char* inputfile, char*outputfile, int size) • Create a PDF that enables the NetSolve server to interface with this function by hand or by using PDF GUI generator
Software FFT PDF @PROBLEM fft @INCLUDE </avocado/homes/lehrter/my_netfuncs/libfpga.h> @LIB /avocado/homes/lehrter/my_netfuncs/libfpga.a @LANGUAGE C @MAJOR ROW @PATH /fpga/ …
Software FFT PDF Cont. … @DESCRIPTION It performs an in-place decimation-in-frequency operation (Sande-Tukey FFT), leaving the output shuffled. Bit reversal is not performed. @INPUT 2 @OBJECT FILE CHAR infile input file @OBJECT SCALAR I size pointer to size …
Software FFT PDF Cont. … @OUTPUT 1 @OBJECT FILE CHAR outfile output file @CALLINGSEQUENCE @ARG I0 @ARG O0 @ARG I1 @CODE fft(@I0@, @O0@,*@I1@); @END_CODE
Hardware FFT • Interface to hardware version of FFT is: void ffta(char* inputfile, char* outputfile, int size) • PDF for ffta is very similar to fft PDF except: • @PROBLEM ffta • @CODE ffta(@I0@, @O0@, *@I1@); @END_CODE
Server Configuration File … @PROBLEMS: ./problems/testing ./problems/qsort ./problems/mandelbrot ./problems/blas_subset ./problems/lapack_subset ./problems/fft ./problems/ffta
Client Code Example for fft #include <stdio.h> #include "netsolve.h" main(int argc, char **argv) { int info, result, a; a=atoi(argv[3]); info = netsl("fft()", argv[1], argv[2], &a);
Client Code for fft cont. if(info < 0) { netslerr(info); exit(0); } if(info != 0) printf("cannot solve\n"); else printf("problem fft solved \n"); }
Client Code for ffta • Client code for calling ffta is similar to fft client code except a different function is requested from NetSolve • info = netsl("ffta()", argv[1], argv[2], &a);
Client Code Makefile NETSOLVE_ROOT = /home/lehrter/NetSolve-1.4 NETSOLVE_ARCH = i686_pc_linux_gnu CC = gcc INCDIR = -I$(NETSOLVE_ROOT)/include NETSOLVECLIB = $(NETSOLVE_ROOT)/lib/$(NETSOLVE_ARCH)/libnetsolve.a CFLAGS = $(INCDIR) -g LIBS = -lnsl test-fftns: test-fftns.c $(CC) $(CFLAGS) -o $@ test-fftns.c $(NETSOLVECLIB) $(LIBS) test-fftans: test-fftans.c $(CC) $(CFLAGS) -o $@ test-fftans.c $(NETSOLVECLIB) $(LIBS)
Running Client Code • setenv NETSOLVE_AGENT utk1 • test-fftns infile outfile 512 Initializing NetSolve... Initializing NetSolve Complete Sending Input to Server utk1 Downloading Output from Server utk1 problem fft solved • test-fftans infile outfile 512
VHDL programmer Synthesis Server administrator NetSolve server Client Request Software programmer Request results Behind the Scenes of the Client Code VHDL code Configuration file Software and Hardware functions PDFs, Libraries
Implementations • Fast Fourier Transform (FFT) • Data Encryption Standard algorithm (DES) • Image Backprojection algorithm
Conclusions • ECE GSC will offer hardware acceleration to general users • Remote users can benefit from these online resources • Resources are available through an efficient and easy-to-use interface
Future Work • Determine how much speedup is achieved through hardware implementation of prototype functions • Further increase the ECE GSC capabilities • Find appropriate server benchmarking techniques for the ECE GSC hardware • Create code that detects the current configuration loaded on the FPGA