Do not remove this notice.

Copyright Notice

COMMMONWEALTH OF AUSTRALIACopyright Regulations 1969

WARNING

This material has been produced and communicated to you by or on behalf of the University of South Australia pursuant to Part VB of the

Copyright Act 1968 (the Act).

The material in this communication may be subject to copyright under the Act. Any further reproduction or communication of this material by you

may be the subject of copyright protection under the Act.

Do not remove this notice.

Outline

Motivation and Introduction

Problem description

Our approach

Results and Conclusion

• DPR in UAVs (power saving)• Complex applications• Swarm (multiple FPGAs)• Problem definition (How do you develop

adaptive applications in this scenario – so that they can migrate from one platform to another – need for a high level abstraction/support/framework; maintaining the parallism – mapping issues)

Motivation

Motivation

• UAVs Limited power

complex signal / image processing applications

FPGAs

• Swarm of UAVs Constant surveillance – xx days Cooperative applications:

tracking, geo-referencing, bush fire monitoring

Can we do distributed computing with multiple FPGAs?

Migrating applications – dying UAV Larger application – distribute it in the

Swarm

Motivation

New AppUAV – 1 (FPGA)

UAV – 2 (FPGA)

• Mobility of Reconfigurable Applications– If one UAV fails– Can the state of a FPGA be

migrated during runtime?

• New App – lack of computational resources– Distribute over a network of

FPGAs

• Module based design of hardware – single platform ReconfigME

• Platform dependency (like the slot machines – hard to develop application in true module based fashion – need a standardization for module reusability)

• Module based development is hindered because – state saving problem and inter module data dependencies

Introduction

Background

App

Netlist

ReconfigME

• Hardware modules– Independent – Reusable – Third party

• Dynamic Reconfiguration– Slot based– ReconfigME

• Adaptive applications– Swapping of modules

during runtime – Detection / Tracking

Application Development

• 1 – D and 2 – D reconfigurable framework exists– Runtime placement and routing – Not in the application development level

• Application development is difficult– Need to be have core hardware knowledge– Even when third party modules are available; developers need to

worry about state saving– Inter module communication

• More complicated with multiple FPGAs– Need a higher level simple model

• Benefits• Suitability with this scenario• Limitations (unlimited buffers, limiting will bring

local deadlock – but application developers can restrict the nature of the graphs – hence a more restricted KPN)

Kahn Process Network - KPN

• Details of the UAV platform• Lot of RAM if the buffering exceeds it can

be done in software

UAV Platform

• The KPN nodes are treated as agents• Benefits – mapping problem solved• Rule based agents – migrate from one platform

to another – hence an application will have autonomous KPN nodes distributed in the UAV swarm – brings high adaptability

• Task migration from one platform to another• Failure detection

Agent-based KPN nodes

• At the side give a brief description of ReconfigME

• An overall diagram

Overall Model

• The blob tracking results – make sure this example is used through out the slide if possible

Results

• The work represents a first try, yeat to be tested on a highly resourceful platform – speed, but can be improved on faster boards, custom designed high speed RF modems

• Future work – the agents to be built as hardware and more work on fault tolerance.

Discussion

• How to use a network of geographically separated FPGAs for streaming applications ?

• Can we bring a standardization to the state saving problem ?

• How to map applications over a number of FPGAs ?

Conclusion