1 / 18

University of South Australia

University of South Australia. Distributed Reconfiguration. Avishek Chakraborty, David Kearney, Mark Jasiunas. Outline. Motivation Background Our approach Experiment Conclusion. Motivation. UAVs Limited power complex signal / image processing applications FPGAs Swarm of UAVs

marli
Download Presentation

University of South Australia

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. University of South Australia Distributed Reconfiguration Avishek Chakraborty, David Kearney, Mark Jasiunas

  2. Outline • Motivation • Background • Our approach • Experiment • Conclusion

  3. Motivation • UAVs • Limited power • complex signal / image processing applications • FPGAs • Swarm of UAVs • Constant surveillance – 52 hrs* • 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

  4. Motivation • Mobility of Reconfigurable Applications • If one UAV fails • Any other king of internal fault • Can the state of a FPGA be migrated during runtime? • New App – lack of computational resources • Distribute over a network of FPGAs UAV – 1 (FPGA) New App UAV – 2 (FPGA)

  5. Background App • Hardware modules • Independent • Reusable • Third party • Dynamic Reconfiguration • Slot based • ReconfigME • Adaptive applications • Swapping of modules during runtime • Detection / Tracking Netlist ReconfigME

  6. Background ReconfigME • ReconfigME • A preemptive framework • A proxy based connection between SW and HW running on the FPGA board • Built to support streaming applications but application developers had to do the check pointing tasks • Currently there are quite a few number of frameworks that supports slot / tile based reconfiguration

  7. 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 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

  8. Kahn Process Network - KPN • Process Networks • Communicates via infinite FIFOs • Writing channel is unblocking but reading is blocking • Benefits • Deterministic • Concurrency can be implemented safely • Inherently distributed in nature • Distributed memory • Suits with module based design • Applications can be easily represented as KPN nodes

  9. Kahn Process Network - KPN Capturing State of a distributed application • KPN buffers as registers • Application states are stored in registers • If the buffers are saved then application can be preempted restarted again from the same position • Hence the whole application can be migrated to another FPGA • A high-level framework is needed • Storing / restoring of buffers • Connection between the modules • To use the modules in a plug and play fashion a c b d

  10. Kahn Process Network - KPN Buffer Limits • Implementation KPN buffers cannot be infinite • Though some have proposed virtually infinite buffers • The above is directed acyclic graph that may experience deadlock (Thomas M. Parks 1987) • Such constructs can be avoided • In KahnME buffering is done in software but this can be done in HW as well

  11. Agent-based KPN nodes AGENT • The KPN nodes as Agents • The nodes are autonomous • Migrates to the most suitable platform • A solution for distributed mapping • Agent encapsulates the KPN node as well as the input buffer • Making them mobile with the state • Migrate from one FPGA to another KPN node Buffer State-less State-full

  12. Agent-based KPN nodes • Rule based Agents • Conditions for migration • The rule engine runs in a separate thread • Rules are written in a XML file • Consists of HW and SW part • The SW part consists of the API to connect to the FPGA and the Migration Control Thread • HW part is the module to be placed on the FPGA Events States Modules Rules Reactions Processing Thread Migration Control Thread Agent ReconfigME API Platform

  13. Agent-based KPN nodes • An agent nodes can be classified as: • Source, Sink, and Process • Source / Sink virtualizes the underlying hardware, like drivers • Basic elements of any application • Subtle issues: migration of source and sinks • Can be migrated! but not physically • The agent will look for a similar source/sink in the swarm • What if the platform along with source / sink node is dies ? • Failure detections Source Process Sink

  14. Overall Model KahnME FPGA FPGA FPGA FPGA ReconfigME ReconfigME ReconfigME ReconfigME

  15. Tracking Experiment • Blue – B tracking experiment • Two Stationary UAV platforms and another Ground-Station • Each UAV platforms having Vertex 1000E FPGA (I know very slow ) • The tracking application searches for a Blue-B • Blue-B Tracker • The application is launched in the Ground-Station • it soon starts searching for appropriate platform • Once the Blue-B is found the agent will migrate to another platform if lost again; we did this by manually moving the camera

  16. Tracking Experiment The three platforms

  17. Tracking Experiment Results • Migration Issues • The migrating agent’s size was 360kB. • Size of the sates 1500 bytes • Rest was of the Blue-B template !! (should have saved it locally but not realistic) • The migrating module consisted of 18.2 kB SW and 492 kB HW (EDIF) • Hence any typical agent will need around 1.5 kB to 672 kB of data during the migration • More Improvements • By compressing the data • In practical situation migrations will be less • Newer board

  18. Conclusion • This work represents a first try to run application in a geographically distributed network of FPGAS – Distributed Reconfiguration • We have argued that there is a need to standardized state saving techniques to built frameworks for DPR – reusable modules • We have proposed that KPN buffers can be treated as registers holding states • We have proposed to treat KPN nodes as autonomous agents to solve the problem of distributed reconfiguration

More Related