Copyright Notice
Do not remove this notice.
COMMMONWEALTH OF AUSTRALIA
Copyright 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
Motivation
•
•
•
•
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
• 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
• Mobility of Reconfigurable
Applications
– If one UAV fails
– Can the state of a FPGA be
migrated during runtime?
New App
UAV – 1 (FPGA)
• New App – lack of
computational resources
– Distribute over a network of
FPGAs
UAV – 2 (FPGA)
Introduction
• 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
Background
• Hardware modules
App
– Independent
– Reusable
– Third party
• Dynamic Reconfiguration
– Slot based
– ReconfigME
• Adaptive applications
– Swapping of modules
during runtime
– Detection / Tracking
ReconfigME
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
Kahn Process Network - KPN
• 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)
UAV Platform
• Details of the UAV platform
• Lot of RAM if the buffering exceeds it can
be done in software
Agent-based KPN nodes
• 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
Overall Model
• At the side give a brief description of
ReconfigME
• An overall diagram
Results
• The blob tracking results – make sure this
example is used through out the slide if
possible
Discussion
• 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.
Conclusion
• 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 ?