SLAAC/ACS API: A Status Report

1. SLAAC/ACS API: A Status Report Virginia Tech Configurable Computing Lab SLAAC Retreat September 1999

2. API Implementation Team • Virginia Tech • API implementation, WildForce node, WildStar node, coordination of API • George Mason University • initial Linux port and port to WildOne node • USC/ISI-East • SLAAC-1 and SLAAC-2 node libraries

3. Problem Definition • A single adaptive computing board is insufficient for many applications • Difficult to move an application from a research laboratory to practical application • Need for application to move to new platforms as they become available without unreasonable effort

4. Solution Approach • Define a platform independent API that allows for configuration and control of a multi-board ACS • Provide efficient implementations of the API for research & field platforms • exploit high speed networking • modular design that performs more complex control tasks on a OS-equipped host

5. Implementation Design • System layer: provides the API to the user; board independent implementation • Control layer: not accessible to user; largely board independent • Node library: provides for control of a specific device; completely board dependent

6. Implementation Status • The entire API has been implemented on a Windows NT-based system and tested on a system of WildForce nodes • This implementation has been ported to the Linux OS • Node libraries have been written for the SLAAC-1 and AMS WildOne boards • Node libraries are being designed/written for SLAAC-2 and the AMS WildStar

7. Platform Independence • An initial port from NT to Linux is complete • We have identified OS-specific features of the API • We are now isolating these features in an OS-specific library that will make porting and maintaining the API simpler

8. Additional Functionality • Board-level register access • ACS_REG_READ(system,node,reg,buffer,size) • ACS_REG_WRITE(system,node,reg,buffer,size) • Attribute management at the system level; allow access to debug/performance info • ACS_ATTR_READ(system,node,attr,buffer,size • ACS_ATTR_WRITE(system,node,attr,buffer,size

9. The current API allows a device to be configured at the API level by sending a configuration to a node using the ACS_Configure() subroutine this is sufficient for the Xilinx 4K family in which configurations times dominate network overhead New devices (Virtex, Sanders CSRC) have fast reconfiguration that will make RTR more practical Need to reduce the overhead caused by network and bus transfers of configurations Need to allow for finer control of reconfiguration Support for RTR

10. Styles of Run Time Reconfiguration • Host-Driven RTR • device is reconfigured at the behest of a controlling process • e.g., predetermined sequence of configurations or OS-driven time-sharing between jobs • Data-Driven RTR • device is reconfigured according to the data being processed • e.g., filter selection depending on brightness

11. Host-Driven RTR API Support • Configurations can exist at several levels of memory, for example: • main memory of local/remote computers • PowerPC’s memory • CSRC’s configurations • Need to extend the API to allow for caching of configurations to take advantage of locality • expect configurations to be reused • expect to overlap download w/execution

12. Caching Configurations

13. API Extensions for Host RTR • Current APIs (including the SLAAC) just have a call to send a bitfile to a PE • ACS_Configure() • We will extend the implementation to allow for implicit caching of bitfiles (no change to the API specification) • We will also add routines to allow for explicit user control over caching • cache strategy control • explicit control over placement in caches

14. Data-Driven RTR API Support • To be effective & efficient, data-driven RTR should be managed close to the device • do not want the overhead of having to send a message to the user-level interface to see which configuration should be loaded next • the user must still be able to specify which configurations will be loaded under what conditions • We propose an FSM-based control method

15. FSM Control of Configurations

16. API Extensions for DD RTR • Will build on explicit control of caches defined earlier • User will specify a simple FSM that will control how configurations are switched between cache slots -- ACS_Define_FSM() • This FSM will be executed by the processor controlling that cache -- not by user-level code (in the control process)

17. Integration with JHDL • It would be useful to provide the SLAAC API as a target platform for JHDL • allow for easy retargeting of JHDL to new boards/platforms • allow for control of multi-board systems from JHDL • We have built a prototype interface between the two using JNI to demonstrate feasibility

18. JHDL Integration Plan • The SLAAC API has three important user level objects to map into JHDL • Nodes: the boards in the system • Channels: the logical data paths between nodes • System: the collection of nodes and channels • These objects are explicitly allocated by the user with calls to the SLAAC API • Propose similar calls to instantiate them in JHDL (via JNI calls to the API)

19. JHDL Integration Plan (2) • JHDL provides support for the WildForce board via commands that open the board, close the board, read memory, etc. • the commands map well to the API • need to be changed to allow for the desired node object to be taken as an argument • Channel objects can be represented as a particular type of JHDL Wire that connects FIFOs on separate boards

20. JHDL Integration Plan (3) • Issues requiring more work or presenting difficulties include: • Management/Presentation of a GUI representing a SLAAC API system of multiple nodes • JHDL provides a very useful view, e.g., of the WildForce board • How do we present something similar for the API and for specific boards? • Some implementations of MPI have startup behaviors that don’t lend themselves to integration using JNI

21. Under Construction • Improved Fifo’s for the WildForce board • also useful in fifo design for other boards • Continued development of the multiboard debugger and performance monitor • Tight coupling of Myrinet and ACS board • hampered by lack of information from AMS on WildForce board • should be easier on the SLAAC-1

22. Summary • First version of the API is up and running on multiple platforms • Next version of API with increased functionality is under design • Latest versions of source code and design documents available for download • also on CD-ROM distributed here • For more information visit VT configurable computing website http://www.ccm.ece.vt.edu/