1 / 36

DEEP-3

DEEP-3. Decryption and Encryption of MP3. Project Brief Aims and Goals Partitioning Design Route ASIP Design Route. Application Choice Project Management Early Feedback What Next Conclusions. Structure of Presentation. Project Brief. Problem

verlee
Download Presentation

DEEP-3

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. DEEP-3 Decryption and Encryption of MP3

  2. Project Brief Aims and Goals Partitioning Design Route ASIP Design Route Application Choice Project Management Early Feedback What Next Conclusions Structure of Presentation

  3. Project Brief • Problem • How easy is it to harness the power of re-configurable computing? • How easy is it for Software Engineers?

  4. Introduction • What is re-configurable computing? • “Computing platforms whose architecture can be modified by software to suit the application in question. Such a system may take the form of a Field Programmable Gate Array (FPGA) combined with external memories and processors.” • Why is it of such great interest? • Reduced development costs • Reduced time to market • Hot upgrades • Improved performance (sometimes!)

  5. Current Trends in Reconfigurable Computing • Greater number of gates / higher clock frequencies  increased performance • Greater volumes  reduced costs • C-like hardware description languages  development accessible to software engineers  more effort can be allocated to other parts of the project

  6. Project Aims • To investigate hardware/software co-design methods • By considering two design routes using a non-trivial application as a test-bench • By measuring amount of effort required for each design route • Using direct and indirect measures e.g. • Lines of code, number of gates used and execution time • Perceived complexity • Comparing the performance of the prototypes with the software only version

  7. Project Goals • To produce and demonstrate two working prototypes • To benchmark the prototypes and the software only solution

  8. Hardware / Software Partitioning

  9. Partitioning Methodology (1) • C Source developed using Rapid Application Development, then evolved to fixed point implementation • Common to both routes • Profiling • Find “Hot spot” regions within the C source

  10. Partitioning Methodology (2) • Partitioning • Done manually as automated solutions are not very good • Apply partitioning rules • C  Handel C • Design inter/intra process communication, control and synchronisation • Co-Simulation • For Verification and Validation

  11. Partitioning Design Route • Advantages • Conceptually simpler to understand • De Facto Standard therefore more applied examples • Method can be used to produce low power, low cost or high performance • Disadvantages • Done manually • Repeated for every application

  12. ASIP Design

  13. ASIP Methodology (1) • C Source same as Partitioning method • Profiling same as Partitioning method • Also perform static analysis to discover instruction mix and number of registers required • Instruction Set Architecture developed using coarse grain customisation • GCC used as re-targetable compiler • Simulate to validate making necessary changes

  14. ASIP Methodology (2) • RISC (Load Store) Architecture • Based on MIPS • Efficient pipelining • Higher degree of parallelism • Performance advantage • Harvard Architecture • Difficult so use Von Neuman in early stages • VLIW • Improves performance • Only If Time Allows

  15. ASIP Design Route • Advantages • Most of the development effort is writing C • More efficient use of function units than GP • Shorter time to market than more customised hardware design • Reusability • Disadvantages • Extra complexity with compiler alterations

  16. Sound Sample Input Source MP3 Encoding Encrypted MP3 MP3 Decoding Decrypted MP3 Local Storage Distributor Decrypted Decompressed Sound Sample Output Source System Overview • Perceived as a non-trivial application • Both computationally intensive on their own • Different instruction mix (MP3 uses reals crypto uses integers)

  17. Requirements • Functional Requirements • Compress & Encrypt Sound • Decrypt, Decompress & Playback • Non-Functional Requirements • Security • Multiple Input formats • Real Time • User Friendly

  18. MP3 • International Standard • ISO/IEC 11172-3:1993 • Legal Issues • Patented technology • Can be licensed • Based on Psycho-Acoustics model • How the human mind perceives sound

  19. MP3 Encoding • Data sent as audio frames • Difficult to generate a good perceptual model • Very few good quality implementations

  20. MP3 Decoding • Easier than encoding • Intended playback through speakers via FPGA

  21. MP3 Codec Selection • Considered many alternatives • LAME, BlandEnc, Xing, FhG • Criteria used • VBR, Fixed Point, Open Source, Sound Quality, Frequency of Public Domain Usage, Independent Tests • LAME “best” • No Fixed Point

  22. Cryptography • Requirements • Open Standard, Industry Strength, Integrity Check, Authentication • Legal Issues • Patents, Key Strengths • Algorithms • Public / Private Key, One-Way Hashes, Digital Signatures

  23. RSA Algorithm • Security lies in intangibility of factoring large integers • Key distribution problem • Compare Padlock & Key • Algorithm based on fast modular exponentiation. • Good test of FPGA performance

  24. RSA Walkthrough • Diagram Here

  25. Conceptual Model & Walkthrough • Login • Related to encryption

  26. Encoding & Encryption

  27. Decryption & Playback

  28. System Architecture Storage Device Memory (RAM) CD-ROM IDE Bus Host CPU (x86) Microphone DMA PCI Bus Sound Card RC-1000 Board (FPGA – Memory) Speakers Line In

  29. FPGA Board Architecture

  30. Time Management • Application developed rapidly • Leave adequate time for • Testing • Integration • Implementation (Handel C) • Derived from reviewing why previous group’s system failed to be delivered on schedule

  31. Risk Management – Identified Risks • ASIP Design • No prior experience • Conceptually More challenging • Resources • Limited availability of FPGA • Handel C • No prior experience before project • Task Complexity • Time Management • Slow Start

  32. Risk Management – Managing Risks • Spiral Model • Incremental with regular reviews • Buddy Buddy System • Dedicated Handel C “expert” • Achievable goals • Plenty of Research

  33. Early Feedback • Profiling results • Early identification of “hotspot” functions as psycho analysis and Huffman coding • Metrics • One week to grasp partitioning • Ten weeks to grasp ASIP design • Handel C • Simple programs implemented

  34. What Next? • First Application Prototype • Software only • Second Prototype • Fixed Point, software only • Incrementally More Complex Handel C coding • Further prototypes with the design processes

  35. Summary • Presented the project aims and vision • Presented two opposing development methods • Presented an overview of the application to be used • Identified risks and how to manage them • Presented initial results • Planned further work

  36. Conclusion • Project remains on schedule • Good progress made • Lots more to do

More Related