Velocity-EHF for Android
- 1. Android in Hybrid Architectures iVeia’s Velocity Embedded Hybrid Framework for Android
- 2. What is Hybrid Processing? • A hybrid processing platform consists of two or more different types of computational units, one typically being a general-purpose processor (GPP) Also referred to as heterogeneous computing • In the context of this presentation, a platform consisting of GPP and field-programmable gate array (FPGA) computational units
- 3. Benefits of Hybrid Processing • Computing that can be specialized to target a specific set of applications • Provides Massive parallelism and provides “glue” between the compute engine and specialized I/O • Due to specialization, often superior to frequency scaling and multi-core homogeneous processing in terms of power, size, and cost
- 4. Hybrid ArchitectureExamples USB Ether-net Addr, Data, Special-ized GPP: ARM SoC Control FPGA I/O GPIO UARTs • Discrete devices connected via general-purpose External memory bus GPIO USB Special-ized GPP: Intel Atom, PCIe FPGA I/O Ether-net PowerPC UARTs • Discrete devices connected via External Peripheral: PCI Express USB AXI Ethernet GPP: Dual-Core Special-ized AXI FPGA I/O GPIO ARM AXI UARTs • Processor core(s) and FPGA fabric integrated on a single device
- 5. Additional Features • The FPGA fabric is memory mapped to the host processor, simplifying software driver design • The logic can be configured by the host processor so one platform can be targeted to multiple applications • The FPGA fabric may be used to extend the I/O capability of the GPP
- 6. Android Is: • Robust open-source software platform • Designed for mobile devices • Free development tools, a rich development environment • Large fast-growing community and eco-system • Full-featured application framework • Open-source, but with business-friendly licensing (vs. GPL)
- 7. Benefits of Android and Hybrid Processing • Extend the capabilities of a mobile Android device with high-performance specialized acceleration • Interface non-traditional peripherals to a mobile Android device • Add a robust user interface to a device / system (whether the device is mobile or not)
- 8. iVeia Real-World Examples • Handheld Speech-to-Speech Translator • Medical Sterilizer • Controlled Drug Dispenser • Military Radio • Imaging Enhancement
- 9. Android as an Embedded OS • Rigid application framework • Difficult to add custom hardware/features • Security protects hardware (i.e., mobile phone) from any malicious software, but cumbersome for embedded applications • Divergence from traditional Linux • Bionic vs. GLIBC C Library • Binder vs. POSIX for IPC • Non-FHS filesystem • Wakelocks
- 10. Custom Service Solution • The “proper” way to add non-standard device support is using Android’s HAL • Done so through a system service • Just like stock Android services, application interfaces to service using System Server and Service Manager • Drawback: Requires several custom code modules to implement
- 11. Custom Service Stack App Custom App Framework / APIs Android System Server Java Custom Service JNI Android Hardware Library (.so) C Code Linux Kernel Device Driver (/dev/…) Hardware
- 12. Custom Service Coding Elements • Linux Device Driver / Kernel Module • Hardware Module • Built into Android SDK interfaces with Linux device driver • Service’s Java Native Interface (JNI)Code • Loads and interfaces with hardware module • Service’s Java code • Interfaces with hardware through JNI • SystemServer.java • Modified to register new service • Android Interface Definition Language file • Used to expose service’s API to applications After Rebuild • Code can now be added to the App to access the new service
- 13. Custom Service: Coding Modify App to Use New Service App my_service.aidl App Framework / APIs Modify SystemServer.java System Server my_service.java Custom Service my_lib.c my_jni.cpp Hardware Library (.so) Device Driver (/dev/…) my_driver.c Hardware
- 14. Android and Programmable Logic • As shown, adding new devices/peripherals in Android is tedious • In re-programmable logic, hardware can change between code revisions, boots, even at run-time • Re-writing device support for each possible logic design would be time-consuming and expensive • Solution: Create a single framework to support multiple designs
- 15. Hybrid Framework • Application “container” • Includes both the software application and programmable logic application • Develop a standard set of methods • Interfacing software and logic applications • Develop programmable logic IP and software • Drivers, libraries, and APIs to facilitate this interface
- 16. Software Container • Android framework provides the “container” for the software application • System service (e.x., PLService) bridges Android framework to programmable logic framework through HAL library • Linux-level device drivers access programmable logic through memory-mapped interface • Device drivers abstract GPP<->PL interconnect mechanism
- 17. Android Hybrid Framework SW App App Framework / APIs Application System Server Software PLService Hardware/Logic Hardware Library (.so) Device Driver (/dev/…) GPP<->PL Interconnect Interface IP PL Framework PL App
- 18. Programmable Logic Container • A set of well-defined physical interfaces and protocols that are identical between architectures • IP blocks abstract interfaces from the GPP<->PL interconnect mechanism • Essentially a “BSP” for programmable logic
- 19. Velocity-EHF for Android SW App • Application framework &portability layer App Framework / APIs • Specifically suited for hybrid target platforms System Server and applications • Designed to provide standard interfaces PLService • Both software and programmable logic applications. Hardware Library (.so) • Comprehensive Suite Device Driver (/dev/…) • Programmable logic IP blocks GPP<->PL Interconnect • Software libraries Interface IP PL Framework PL App Framework ported supporting Hybrid Processing architectures Zynq, TI OMAP & PowerPC
- 20. Hybrid FrameworkAdvantages • No need to code Android HAL support and drivers for each new FPGA design • Creates portability layer between platforms • Abstraction simplifies app development • Software and hardware can be developed independently, reducing integration stages • Easier partitioning and development • Simplifies management of applications
- 21. Velocity-EHF for Zynq: PL Container Zynq PS / CPUs Dual Cortex-A9 ARM Cores Zynq PL<->PS AXI AXI FCLK / IRQ Interconnect HP GP FRST PL2PS AXI AXI Clk/Rst Events PL Framework Intf IP ZAP IP OCP IP Gen IP Power Mgmt Clks, Rsts, Notifications Transfer Conrol / Status Data PL Framework and App PL App PL Framework Hardware Specialized I/O
- 22. Velocity-EHF for Zynq: SW Container App App Framework / APIs Android Framework System Server Android System Service VEHFService libzap libocp libplsys libevents Android Hardware Modules .so .so .so .so /dev/pls /dev/iv_e Linux Device Drivers /dev/zap /dev/ocp vents ys AXI AXI FCLK / IRQ Zynq PL<->PS Interconnect HP GP FRST PL2PS AXI AXI Clk/Rst Events FPGA Framework Intf IP ZAP IP OCP IP Gen IP
- 23. Velocity-EHF Advantages • FPGA can be “wiped” and re-configured at run-time based on application request • Support for multiple programmable logic containers • Each PL container could support an independent software application • Abstrated complex arbitration in both PL interface IP and in the Android EHF service • Future development: partial reconfiguration to dynamically allocate containers based on software demand
- 24. Conclusion • Developing Android support to interface multiple differing programmable logic designs is time consuming and expensive • The Velocity-EHF framework eliminates the problem and provides an application-ready environment • The framework improves standardization, portability,CPU/logic partitioning
Editor's Notes
- #11: Service Definition from android.com: “A Service is an application component that can perform long-running operations in the background and does not provide a user interface. Another application component can start a service and it will continue to run in the background even if the user switches to another application. Additionally, a component can bind to a service to interact with it and even perform interprocess communication (IPC). For example, a service might handle network transactions, play music, perform file I/O, or interact with a content provider, all from the background.”
- #22: Pose a problemProblem statement: diff possibliities How do you leverage this - What is the methodolgy – C code to FPGA programmable logicGP ports for -Control registers access for peripehrals, vs. streaming data HW portsSeparation between GP and HP portsThe figure below shows the Xilinx® Zynq™-7000 All Programmable SOC high level view combining a tightly coupled Dual Cortex-A9 processing system with significant amounts of programmable logic. This combination provides the flexibility and scalability of an FPGA combined with the efficiency of a high-performance ASIC-based processing system. The large number of connections between the processing system and the programmable logic minimizes communication bottlenecks and enables access both from the processing system to accelerators and peripherals in the programmable logic and from the programmable logic to peripherals and memory interfaces in the processing system. In particular, the Zynq-7000 All Programmable SOC includes a number of General Purpose (GP) AXI3 Master ports, which are primarily used for passing control register information from the processor to the FPGA fabric, and number of High Performance (HP) AXI3 Slave ports, which are primarily used in combination with DMA peripherals in the programmable logic to transfer data to and from external memories. In addition, the Zynq-7000 All Programmable SOC exposes the ARM Accelerator Coherency Port (ACP) to the programmable logic as an AXI Slave interface that can be used in combination with DMA peripherals in the programmable logic to transfer data directly to and from the processor caches.. In addition, system architects and developers can now look at system level performance encompassing both the processing system and the programmable logic in a single device. As part of the optimization process, computationally expensive algorithms can be transferred from the processing system into the programmable logic.Introduction to methodologyUsing this platform – these are the design tasksFlexibility – customizeable ASSP – in multi-dimensionsArchitectureAcceleration