slaac acs api a status report n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
SLAAC/ACS API: A Status Report PowerPoint Presentation
Download Presentation
SLAAC/ACS API: A Status Report

Loading in 2 Seconds...

play fullscreen
1 / 22

SLAAC/ACS API: A Status Report - PowerPoint PPT Presentation


  • 96 Views
  • Uploaded on

SLAAC/ACS API: A Status Report. Virginia Tech Configurable Computing Lab SLAAC Retreat September 1999. 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'SLAAC/ACS API: A Status Report' - caesar-mcclure


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slaac acs api a status report

SLAAC/ACS API: A Status Report

Virginia Tech

Configurable Computing Lab

SLAAC Retreat September 1999

api implementation team
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
problem definition
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
solution approach
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
implementation design
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
implementation status
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
platform independence
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
additional functionality
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
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

Support for RTR
slide10

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
slide11

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
slide13

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
slide14

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
slide16

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)
integration with jhdl
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
jhdl integration plan
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)
jhdl integration plan 2
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
jhdl integration plan 3
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
under construction
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
summary
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/