Automated Interface Generation for Remote Access to Adaptive Computing Resources

1. Automated Interface Generation for Remote Access to Adaptive Computing Resources Christopher C. Doss and Clay S. Gloster ccdoss@eos.ncsu.edu gloster@eos.ncsu.edu Electrical & Computer Engineering Department North Carolina State University http://www4.ncsu.edu/eos/users/c/ccdoss/public_html/RARE/FeW.html Poster Number: P11

2. Overview of Poster Presentation • This poster presentation illustrates North Carolina State University’s framework for allowing remote clients to access our adaptive computing resource. • We show the process used to modify C programs so they can access our adaptive compute server from a remote client. • We present a tool that generates the required files for this transition from a C program to a set of C and Java programs that can use our adaptive computing resource.

3. Remote Adaptive computing Resource Environment (RARE) Client Adaptive Compute Server Input Data Method Invocations Outputs • North Carolina State University’s (NCSU) RARE framework allows any client to interact with adaptive computing resources attached to server

4. Motivation for NCSU’s RARE • Adaptive computing has emerged as a viable computing option for • computationally intensive applications. • Control of remote adaptive computing resources is desirable for • space exploration and interaction with hazardous materials. • Research groups often have a limited number of adaptive computing • resources. • Our research extends the use of adaptive computers to parallel the • incorporation of an application server. • RARE is a framework for accessing adaptive computing resources • from a remote client.

5. Using the Java Native Interface (JNI) to Call Software Written in C/C++ Native Method Interface (NMI) JDK main.java function.c Stub files • Allows Java to call functions written in C/C++

6. Using JNI to Interface to an FPGA Board Traditional C Interface: C function interacts with FPGA using the Application Programming Interface (API) main.c FPGA Board API New Java Interface: Java method interacts with FPGA Native Method Interface (NMI) JDK main.java FPGA Board Stub files API

7. Using Java’s Remote Method Invocation (RMI) Server Client client.java with RMI links Internet server.java with RMI links local.java remote.java • With RMI, the client can execute methods locally or remotely on the server

8. Combining JNI and RMI to Call Local/Remote and Normal/Native Methods Server Client Internet client.java with RMI links server.java with RMI links local.java remote.java NMI NMI local.c remote.c • Client can call Java, C, or C++ routines locally or remotely on the server

9. Combining JNI, RMI, and FPGA API to Form RARE Framework Server Client client.java with RMI links server.java with RMI links Internet method.java NMI method.java NMI NMI NMI function.c API FPGA function.c API FPGA function.c function.c • Client can interact with remote adaptive/reconfigurable computing resource

10. Analyze Program Implement Hardware Modules Design RMI (Automated by FeW) Design Controller Determine FPGA Architecture Map Hardware Modules to FPGA Design Software Interface Determine Host/Hardware Interface Perform Precision Analysis Mapping a C Program to NCSU’s RARE Design JNI (Automated by FeW

11. Step 1: Perform Analysis of Input Program • Use a profiler to determine the computationally intensive portions • of the program. • Determine control and data dependencies in the program. • Perform dead code elimination and strength reduction. • Determine computational components required by data path (i.e. • multipliers, adders, etc.).

12. Step 2: Determine FPGA Board Architecture that Best Matches Application • Examine several available FPGA board architectures. • Determine number of FPGA’s required by the application. • Determine memory storage requirements. • Establish reconfigurable computing application development • environment that will be used to assist in the mapping • process.

13. Step 3: Determine Method Host will Interface with Hardware • Use analysis performed in first step to determine which portions • of the program will be mapped to hardware and which portions • will remain in software. • Determine method the host program will feed inputs to and receive • outputs from the hardware. • Determine method the host will perform other tasks, such as • initialization and synchronization.

14. Step 4: Perform Precision Analysis on Program • Due to current FPGA size limitations, fixed-point arithmetic may • be required. • Extensive simulations must be conducted to ensure precision of • the results generated by data path modules is acceptable. • Using excessive bits in computations leads to a design that is large • and may not fit in the space available on the FPGA's.

15. Step 5: Implement Data Path Modules Required for Program • Develop VHDL models of required components and define • their interconnection. • Design modules specific to this design, including complex • hardware modules such as histogram functions. • Verify functionality of each component and entire data path • with a simulator.

16. Step 6: Design Controller for Hardware • Design a controller for the hardware modules in the data path. • The controller implements a finite state machine that determines • when each operation must be performed. • The controller must also interact with the host processor for • synchronization. • Standard control functions specific to the FPGA board architecture • should be designed to facilitate re-use.

17. Step 7: Design Software Interface to Hardware • Determine the method in which the host program will access • the hardware board. • This interaction includes: initializing the board, loading • the hardware image onto the board, loading inputs to the board, • retrieving outputs from the board, closing the board, and any • synchronizations and handshaking required. • Often, there are software application program interfaces (API) • shipped with the FPGA board that ease the interaction with the • board.

18. Step 8: Incrementally Map Hardware Modules to FPGA • Incrementally map hardware modules to the FPGA. • Start with the controller and ensure the host can access it, and the • controller performs synchronization steps as planned. • Map first component of data path and ensure the host and controller • can access it. • Map successive components of data path, ensuring the host • and controller can access them properly. • Repeat process until either the entire hardware section is mapped • or the available FPGA resources are exhausted. • The designer may need to repartition the input program and • redesign the controller after this step.

19. Step 9: Design Java Native Interface • Determine the functions (methods) that will be accessible to the user. • Often the methods used to access the board are written in C,C++, • or some other language. • Use the Java Native Interface to allow Java program to interface • with the functions that access the board. • Note that this step assumes the software API's are written in • some language such as C. If the software API's are written in Java, • this step can be skipped.

20. Step 10: Design Remote Method Invocation Interface • Determine method in which other computers will be able • to access the board and this program. • Determine functions that will be accessible from remote computers. • Use Java’s Remote Method Invocation procedure to allow other • computers to call these functions.

21. Overview of FeW • FeW assists the designer of a remote reconfigurable computing • application by automatically generating the files typically • associated with these designs. • Files created include: • C files to interface with the hardware modules • C files that comprise the dynamic link libraries • to link with Java source native methods • Java client and server stubs for communication • via Remote Method Invocation (RMI). • Java class files to interface with native methods.

22. File Writer (FeW) Eases Interaction with RARE RMI Interface class file for client and server myprog.java myprog.c FeW RMI server implementation class file myprogImpl.java myprog.flag JNI server class file for calls to C/FPGA Board myprogNative.java • FeW examines user program and flag file, and generates files required for • RMI and JNI.

23. Input and Output Formats for FeW • The input to the system is a C program and a flag file. • The flag file contains a flag that specifies which functions will be • mapped to hardware, and which functions need to be accessible • from the resulting Java classes. • The output of the system will be several files that the designer may • use to implement the design. • These files will contain stub functions that the designer will need to • fill in.

24. Operation of FeW • Program is parsed using PROLANGS Analysis Framework. • Relevant procedure information is retrieved from the program: • Procedure name. • Return type. • Parameter list. • C source code. • Information is used to generate the required stub files and • the complete local and remote versions of the function in C.

25. Conclusions • This poster presents RARE, an adaptive computing • environment developed at N.C. State University. • We also illustrate the steps necessary to map an application to • the RARE framework. • A close examination of the steps revealed those that can be quickly • automated to help the design engineer. • These steps result in files the engineer must augment to finish the • design. • Stubs for these files are produced by FeW, the File Writer component • of RARE.