SLAAC/ACS API: A Status Report

1
SLAAC/ACS API A Status Report
Virginia Tech Configurable Computing Lab SLAAC
Retreat March 1999
2
The Virginia Tech SLAAC Team

• Dr. Peter Athanas
• Dr. Mark Jones
• Heather Hill
• Emad Ibrahim
• Zahi Nakad
• Kuan Yao
• Diron Driver
• Karen Chen

• Chris Twaddle
• Jonathan Scott
• Luke Scharf
• Lou Pochet
• John Shiflett
• Peng Peng
• Sarah Airey
• Chris Laughlin

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
Representative Field System

• Embedded, distributed system
• sensor nodes
• actuator nodes
• adaptive computing nodes
• Limited OS/microprocessor support on most nodes
• Heterogeneous network

6
Tower of Power

• 16 PII 300 MHz PCs w/ 256 MB RAM
• Myrinet and Fast Ethernet Switched Networks
• AMS Wildforce Reconfigurable Computing Engine

7
Project Timeline
Multiboard Debugger
Kickoff
Intervention Free Operation
SLAAC-1 2 Integration
Nov 98
Aug 99
Feb 99
May 99
Multiboard API
Applications
8
Requirements (1)

• Address wide range of applications on cluster and
  embedded systems
• Portability
• Must allow application porting without source
  modification
• Simplicity
• Single program for system control

9
Requirements (2)

• Expandability
• Support new node types
• Performance
• Must keep an acceptable level of performance

10
Requirements (3)

• Simplicity
• Single host program initializes and controls
  system
• Host process controls host node, control process
  runs on others
• Standard functions provide unified control of
  hardware and communication

11
Requirements (4)

• Expandability
• Object Oriented Implementation
• Inherit node class and modify functions
• Performance
• Zero copy buffers
• Recognizes differences between remote and local
  node to reduce overhead

12
System Creation Functions

• ACS_Initialize
• Parses command line.
• Initializes globals.
• ACS_System_Create
• Allocates nodes and channels.
• Creates opaque system object in host program.
• Same host program can manage multiple systems.

2
0
3
1
0
2
1
3

• Nodes and channels are logically numbered in
  order of creation.
• Host is node zero.

13
Memory Access Functions

• ACS_Read()
• Gets block of memory from (system, node, address,
  count) into user buffer.
• ACS_Write()
• Puts block of memory from user buffer to (system,
  node, address, count).

• ACS_Copy()
• Copies memory from (node1, address1) to (node2,
  address2) directly.
• ACS_Interrupt()
• Generates an interrupt signal at node.

14
Streaming Data Functions

• Each node/system has a set of FIFO buffers.
• Channels connect two FIFO buffers.
• Arbitrary streaming-data topologies supported.

• ACS_Enqueue()
• put user data into FIFO
• ACS_Dequeue()
• get user data from FIFO

1
FIFO 0
0
FIFO 1
FIFO 2
2
FIFO 3
15
PerformanceMonitor

• Dynamic Topology Display
• Performance Metrics
• Playback (future)

16
ACS Multiboard Debugger

• Based on Boardscope and Jbits
• Will provide
• Waveforms
• State Status
• Channel Status
• Interfaces through SLAAC API

17
Applications

• Video/Image processing
• Real Time Filtering
• Super Real Time Wireless Channel Model
• 2-D FIR Filter
• 2-D Wavelet and Image Interpolator

18
Deficiencies

• FIFO Limitations
• Too small and slow for efficient bus transfer
• Drivers limit I/O performance
• Cannot keep board supplied with data to process
• Closed Board Architecture
• Closed Driver Source
• Benefits of SLAAC-1 2
• Higher I/O throughput capability
• Open Architecture model

19
Hostless Integration of ACS Node and Myrinet

• Allows for Communication without Host
  Intervention
• Lower latency
• More efficient use of bus bandwidth
• Protocol with LANai
• Header fields determine packet destination within
  a node
• DMA transfers initiated by LANai

20
Future Work

• Support for RunTime Reconfiguration (RTR)
• API implementation for embedded systems
• System level management of multiple programs

21
Summary

• Latest versions of source code and design
  documents available for download
• For more information visit TOP websitehttp//acam
  ar.visc.ece.vt.edu/