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

SLAAC/ACS API: A Status Report

Embed Size (px)

DESCRIPTION

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 - PowerPoint PPT Presentation

Citation preview

Page 1: SLAAC/ACS API:  A Status Report

SLAAC/ACS API: SLAAC/ACS API: A Status ReportA Status Report

Virginia TechConfigurable Computing LabSLAAC Retreat September 1999

Page 2: SLAAC/ACS API:  A Status Report

API Implementation TeamAPI Implementation Team

• Virginia TechVirginia Tech– API implementation, WildForce node, API implementation, WildForce node,

WildStar node, coordination of APIWildStar node, coordination of API

• George Mason University George Mason University – initial Linux port and port to WildOne initial Linux port and port to WildOne

nodenode

• USC/ISI-EastUSC/ISI-East– SLAAC-1 and SLAAC-2 node librariesSLAAC-1 and SLAAC-2 node libraries

Page 3: SLAAC/ACS API:  A Status Report

Problem DefinitionProblem Definition

• A single adaptive computing board A single adaptive computing board is insufficient for many applicationsis insufficient for many applications

• Difficult to move an application from Difficult to move an application from a research laboratory to practical a research laboratory to practical applicationapplication

• Need for application to move to new Need for application to move to new platforms as they become available platforms as they become available without unreasonable effortwithout unreasonable effort

Page 4: SLAAC/ACS API:  A Status Report

Solution ApproachSolution Approach

• Define a platform independent API Define a platform independent API that allows for configuration and that allows for configuration and control of a multi-board ACS control of a multi-board ACS

• Provide efficient implementations of Provide efficient implementations of the API for research & field platformsthe API for research & field platforms– exploit high speed networkingexploit high speed networking

– modular design that performs more modular design that performs more complex control tasks on a OS-equipped complex control tasks on a OS-equipped hosthost

Page 5: SLAAC/ACS API:  A Status Report

Implementation DesignImplementation Design

• System layer: provides the API to System layer: provides the API to the user; board independent the user; board independent implementationimplementation

• Control layer: not accessible to user; Control layer: not accessible to user; largely board independentlargely board independent

• Node library: provides for control of Node library: provides for control of a specific device; completely board a specific device; completely board dependentdependent

Page 6: SLAAC/ACS API:  A Status Report

Implementation StatusImplementation Status• The entire API has been implemented The entire API has been implemented

on a Windows NT-based system and on a Windows NT-based system and tested on a system of WildForce nodestested on a system of WildForce nodes

• This implementation has been ported This implementation has been ported to the Linux OSto the Linux OS

• Node libraries have been written for Node libraries have been written for the SLAAC-1 and AMS WildOne boardsthe SLAAC-1 and AMS WildOne boards

• Node libraries are being Node libraries are being designed/written for SLAAC-2 and the designed/written for SLAAC-2 and the AMS WildStarAMS WildStar

Page 7: SLAAC/ACS API:  A Status Report

Platform IndependencePlatform Independence

• An initial port from NT to Linux is An initial port from NT to Linux is completecomplete

• We have identified OS-specific We have identified OS-specific features of the APIfeatures of the API

• We are now isolating these features We are now isolating these features in an OS-specific library that will in an OS-specific library that will make porting and maintaining the make porting and maintaining the API simplerAPI simpler

Page 8: SLAAC/ACS API:  A Status Report

Additional FunctionalityAdditional Functionality

• Board-level register accessBoard-level register access– ACS_REG_READ(system,node,reg,buffer,size)ACS_REG_READ(system,node,reg,buffer,size)

– ACS_REG_WRITE(system,node,reg,buffer,size)ACS_REG_WRITE(system,node,reg,buffer,size)

• Attribute management at the system Attribute management at the system level; allow access to level; allow access to debug/performance infodebug/performance info– ACS_ATTR_READ(system,node,attr,buffer,sizeACS_ATTR_READ(system,node,attr,buffer,size

– ACS_ATTR_WRITE(system,node,attr,buffer,sizeACS_ATTR_WRITE(system,node,attr,buffer,size

Page 9: SLAAC/ACS API:  A Status Report

Support for RTRSupport for RTR• The current API allows a device to be The current API allows a device to be

configured at the API level by sending a configured at the API level by sending a configuration to a node using the configuration to a node using the ACS_Configure() subroutineACS_Configure() subroutine– this is sufficient for the Xilinx 4K family in which this is sufficient for the Xilinx 4K family in which

configurations times dominate network overheadconfigurations times dominate network overhead

• New devices (Virtex, Sanders CSRC) have fast New devices (Virtex, Sanders CSRC) have fast reconfiguration that will make RTR more reconfiguration that will make RTR more practicalpractical– Need to reduce the overhead caused by network and Need to reduce the overhead caused by network and

bus transfers of configurationsbus transfers of configurations

– Need to allow for finer control of reconfiguration Need to allow for finer control of reconfiguration

Page 10: SLAAC/ACS API:  A Status Report

Styles of Run Time Styles of Run Time ReconfigurationReconfiguration

• Host-Driven RTRHost-Driven RTR– device is reconfigured at the behest of a device is reconfigured at the behest of a

controlling processcontrolling process

– e.g., predetermined sequence of configurations e.g., predetermined sequence of configurations or OS-driven time-sharing between jobsor OS-driven time-sharing between jobs

• Data-Driven RTRData-Driven RTR– device is reconfigured according to the data device is reconfigured according to the data

being processedbeing processed

– e.g., filter selection depending on brightnesse.g., filter selection depending on brightness

Page 11: SLAAC/ACS API:  A Status Report

Host-Driven RTR API Host-Driven RTR API SupportSupport

• Configurations can exist at several levels of Configurations can exist at several levels of memory, for example:memory, for example:– main memory of local/remote computersmain memory of local/remote computers

– PowerPC’s memoryPowerPC’s memory

– CSRC’s configurationsCSRC’s configurations

• Need to extend the API to allow for caching of Need to extend the API to allow for caching of configurations to take advantage of localityconfigurations to take advantage of locality– expect configurations to be reusedexpect configurations to be reused

– expect to overlap download w/executionexpect to overlap download w/execution

Page 12: SLAAC/ACS API:  A Status Report

Caching ConfigurationsCaching Configurations

Page 13: SLAAC/ACS API:  A Status Report

API Extensions for Host API Extensions for Host RTRRTR

• Current APIs (including the SLAAC) just Current APIs (including the SLAAC) just have a call to send a bitfile to a PEhave a call to send a bitfile to a PE– ACS_Configure()ACS_Configure()

• We will extend the implementation to We will extend the implementation to allow for implicit caching of bitfiles (no allow for implicit caching of bitfiles (no change to the API specification)change to the API specification)

• We will also add routines to allow for We will also add routines to allow for explicit user control over cachingexplicit user control over caching– cache strategy controlcache strategy control

– explicit control over placement in cachesexplicit control over placement in caches

Page 14: SLAAC/ACS API:  A Status Report

Data-Driven RTR API Data-Driven RTR API SupportSupport

• To be effective & efficient, data-driven To be effective & efficient, data-driven RTR should be managed close to the RTR should be managed close to the devicedevice– do not want the overhead of having to send a do not want the overhead of having to send a

message to the user-level interface to see message to the user-level interface to see which configuration should be loaded nextwhich configuration should be loaded next

– the user must still be able to specify which the user must still be able to specify which configurations will be loaded under what configurations will be loaded under what conditionsconditions

• We propose an FSM-based control methodWe propose an FSM-based control method

Page 15: SLAAC/ACS API:  A Status Report

FSM Control of FSM Control of ConfigurationsConfigurations

Page 16: SLAAC/ACS API:  A Status Report

API Extensions for DD RTRAPI Extensions for DD RTR

• Will build on explicit control of caches Will build on explicit control of caches defined earlierdefined earlier

• User will specify a simple FSM that will User will specify a simple FSM that will control how configurations are switched control how configurations are switched between cache slots -- ACS_Define_FSM()between cache slots -- ACS_Define_FSM()

• This FSM will be executed by the This FSM will be executed by the processor controlling that cache -- not by processor controlling that cache -- not by user-level code (in the control process) user-level code (in the control process)

Page 17: SLAAC/ACS API:  A Status Report

Integration with JHDLIntegration with JHDL

• It would be useful to provide the It would be useful to provide the SLAAC API as a target platform for SLAAC API as a target platform for JHDLJHDL– allow for easy retargeting of JHDL to new allow for easy retargeting of JHDL to new

boards/platformsboards/platforms

– allow for control of multi-board systems allow for control of multi-board systems from JHDLfrom JHDL

• We have built a prototype interface We have built a prototype interface between the two using JNI to between the two using JNI to demonstrate feasibilitydemonstrate feasibility

Page 18: SLAAC/ACS API:  A Status Report

JHDL Integration PlanJHDL Integration Plan• The SLAAC API has three important The SLAAC API has three important

user level objects to map into JHDLuser level objects to map into JHDL– Nodes: the boards in the systemNodes: the boards in the system

– Channels: the logical data paths between Channels: the logical data paths between nodesnodes

– System: the collection of nodes and System: the collection of nodes and channelschannels

• These objects are explicitly allocated These objects are explicitly allocated by the user with calls to the SLAAC APIby the user with calls to the SLAAC API

• Propose similar calls to instantiate Propose similar calls to instantiate them in JHDL (via JNI calls to the API)them in JHDL (via JNI calls to the API)

Page 19: SLAAC/ACS API:  A Status Report

JHDL Integration Plan (2)JHDL Integration Plan (2)• JHDL provides support for the JHDL provides support for the

WildForce board via commands that WildForce board via commands that open the board, close the board, read open the board, close the board, read memory, etc.memory, etc.– the commands map well to the APIthe commands map well to the API

– need to be changed to allow for the need to be changed to allow for the desired node object to be taken as an desired node object to be taken as an argumentargument

• Channel objects can be represented Channel objects can be represented as a particular type of JHDL Wire that as a particular type of JHDL Wire that connects FIFOs on separate boardsconnects FIFOs on separate boards

Page 20: SLAAC/ACS API:  A Status Report

JHDL Integration Plan (3)JHDL Integration Plan (3)• Issues requiring more work or Issues requiring more work or

presenting difficulties include:presenting difficulties include:– Management/Presentation of a GUI Management/Presentation of a GUI

representing a SLAAC API system of representing a SLAAC API system of multiple nodesmultiple nodes• JHDL provides a very useful view, e.g., of JHDL provides a very useful view, e.g., of

the WildForce boardthe WildForce board

• How do we present something similar for How do we present something similar for the API and for specific boards?the API and for specific boards?

– Some implementations of MPI have Some implementations of MPI have startup behaviors that don’t lend startup behaviors that don’t lend themselves to integration using JNIthemselves to integration using JNI

Page 21: SLAAC/ACS API:  A Status Report

Under ConstructionUnder Construction

• Improved Fifo’s for the WildForce boardImproved Fifo’s for the WildForce board– also useful in fifo design for other boardsalso useful in fifo design for other boards

• Continued development of the multiboard Continued development of the multiboard debugger and performance monitordebugger and performance monitor

• Tight coupling of Myrinet and ACS boardTight coupling of Myrinet and ACS board– hampered by lack of information from AMS on hampered by lack of information from AMS on

WildForce boardWildForce board

– should be easier on the SLAAC-1should be easier on the SLAAC-1

Page 22: SLAAC/ACS API:  A Status Report

SummarySummary• 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/http://www.ccm.ece.vt.edu/