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
Support for RTR

• 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

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
• PowerPCs memory
• CSRCs 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 dont lend themselves to
  integration using JNI

21
Under Construction

• Improved Fifos 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/