ELG6163 Presentation Geoff Green March 20, 2006 TI Standard for Writing Algorithms.

Slides:



Advertisements
Similar presentations
MicroKernel Pattern Presented by Sahibzada Sami ud din Kashif Khurshid.
Advertisements

.NET Technology. Introduction Overview of.NET What.NET means for Developers, Users and Businesses Two.NET Research Projects:.NET Generics AsmL.
CSCU 411 Software Engineering Chapter 2 Introduction to Software Engineering Management.
Lesson 1-Introducing Basic Network Concepts
Code Composer Studio TM Integrated Development Environment v2 First Intelligent IDE To Offer DSP Application Development For Multi-Processor, Multi-User,
API Design CPSC 315 – Programming Studio Fall 2008 Follows Kernighan and Pike, The Practice of Programming and Joshua Bloch’s Library-Centric Software.
Network Management Overview IACT 918 July 2004 Gene Awyzio SITACS University of Wollongong.
© 2004, D. J. Foreman 1 O/S Organization. © 2004, D. J. Foreman 2 Topics  Basic functions of an OS ■ Dev mgmt ■ Process & resource mgmt ■ Memory mgmt.
XHTML Presenters : Jarkko Lunnas Sakari Laaksonen.
Software Reuse Building software from reusable components Objectives
1 Introduction to Software Engineering Lecture 42 – Communication Skills.
Architectural Design Principles. Outline  Architectural level of design The design of the system in terms of components and connectors and their arrangements.
CS294-6 Reconfigurable Computing Day 3 September 1, 1998 Requirements for Computing Devices.
Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009.
Chapter 2 Introduction to Systems Architecture. Chapter goals Discuss the development of automated computing Describe the general capabilities of a computer.
Principle of Functional Verification Chapter 1~3 Presenter : Fu-Ching Yang.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
Database Management Systems (DBMS)
Detailed Technical Feature Presentation Background Information The Importance of Software Software Roadblocks Development Environment DSP Development Cycle.
Texas Instruments ExpressDSP Algorithm Standard Prof. Brian L. Evans Dept. of Electrical and Computer Engineering The University of Texas at Austin August.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
1 3-General Purpose Processors: Altera Nios II 2 Altera Nios II processor A 32-bit soft core processor from Altera Comes in three cores: Fast, Standard,
Mihir Daptardar Software Engineering 577b Center for Systems and Software Engineering (CSSE) Viterbi School of Engineering 1.
Visual Linker Final presentation.
Department of Computer Science A Static Program Analyzer to increase software reuse Ramakrishnan Venkitaraman and Gopal Gupta.
CS 390- Unix Programming Environment CS 390 Unix Programming Environment Topics to be covered: Distributed Computing Fundamentals.
Proof Carrying Code Zhiwei Lin. Outline Proof-Carrying Code The Design and Implementation of a Certifying Compiler A Proof – Carrying Code Architecture.
Computer Concepts 2014 Chapter 12 Computer Programming.
Component Technology. Challenges Facing the Software Industry Today’s applications are large & complex – time consuming to develop, difficult and costly.
March 27, 2007HPC 07 - Norfolk, VA1 C++ Reflection for High Performance Problem Solving Environments Tharaka Devadithya 1, Kenneth Chiu 2, Wei Lu 1 1.
TMS320 DSP Algorithm Standard: Overview & Rationalization.
CE Operating Systems Lecture 3 Overview of OS functions and structure.
Software Construction Lecture 18 Software Testing.
Static Program Analysis of Embedded Software Ramakrishnan Venkitaraman Graduate Student, Computer Science Advisor: Dr. Gopal Gupta.
Static Program Analyses of DSP Software Systems Ramakrishnan Venkitaraman and Gopal Gupta.
Introduction to Software Engineering. Why SE? Software crisis manifested itself in several ways [1]: ◦ Project running over-time. ◦ Project running over-budget.
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking.
Microsoft Dynamics NAV 2009 and Architecture Overview Name Title Microsoft Corporation.
© 2002 IBM Corporation Confidential | Date | Other Information, if necessary June, 2011 Made available under the Eclipse Public License v Mobile.
Customers work faster and smarter crafting more innovative real-time embedded systems with off-the-shelf software Customer Success Enabled with Proliferation.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
eXpressDSP Modular Application Software Solutions for TMS320 DSPs
Design and Implementation of a Rationale-Based Analysis Tool (RAT) Diploma thesis from Timo Wolf Design and Realization of a Tool for Linking Source Code.
Interoperability Testing. Work done so far WSDL subgroup Generated Web Service Description with aim for maximum interoperability between various SOAP.
CASE (Computer-Aided Software Engineering) Tools Software that is used to support software process activities. Provides software process support by:- –
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Software Engineering Chapter: Computer Aided Software Engineering 1 Chapter : Computer Aided Software Engineering.
G.Govi CERN/IT-DB 1 September 26, 2003 POOL Integration, Testing and Release Procedure Integration  Packages structure  External dependencies  Configuration.
Chapter 1 Basic Concepts of Operating Systems Introduction Software A program is a sequence of instructions that enables the computer to carry.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 5th Edition Copyright © 2015 John Wiley & Sons, Inc. All rights.
Ontologies Reasoning Components Agents Simulations An Overview of Model-Driven Engineering and Architecture Jacques Robin.
軟體的開發策略 Work Faster, Smarter and Craft More Innovative Real- -Time Time Embedded Systems host computerTMS320 DSP RTDX™ DSP/BIOS™ drivers comm alg target.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Design with Vivado IP Integrator
Text2PTO: Modernizing Patent Application Filing A Proposal for Submitting Text Applications to the USPTO.
CLASSIFICATION OF DESIGN PATTERNS Hladchuk Maksym.
cFS Platforms OSAL and PSP
Introduction to Visual Basic. NET,. NET Framework and Visual Studio
Space Plug-and-Play Architecture (SPA) and SSM
Definition CASE tools are software systems that are intended to provide automated support for routine activities in the software process such as editing.
Distribution and components
Software Quality Engineering
TIM 58 Chapter 8: Class and Method Design
CSCI/CMPE 3334 Systems Programming
Chapter 2: The Linux System Part 1
Software Requirements Specification (SRS) Template.
Presentation transcript:

ELG6163 Presentation Geoff Green March 20, 2006 TI Standard for Writing Algorithms

Outline of Presentation Motivation for standard development eXpressDSP vs. XDAIS Description of areas covered by standard XDAIS development tools XDAIS compliance process Demonstration of XDAIS tools

Motivation for Standard Development As DSP systems grow in complexity and time-to-market windows shrink, it is uncommon to find companies that do all development “in-house” There is a large number of third-party vendors of DSP algorithms that offer code that can be “inserted” into a product In this environment, the task of systems integration becomes very important Systems Integration – ensuring that all software components interoperate correctly in the overall design Each vendor provides the algorithm interface in a different manner – leading to a lot of time writing “glueware” – not an effective use of time!

Motivation for Standard Development This motivates the use of a standard for DSP algorithms – a set of rules/ conventions that these algorithms must use to “plug in” to a larger system. for the systems integrator, less effort writing code for each interface for the algorithm developer, ensures that they can market their code to the maximum number of clients without having to support multiple interfaces decreased time-to-market free up skilled resources for algorithm development/creativity/innovation simplifies the evaluation of algorithms from multiple vendors with the ability to quickly plug out and plug in various algorithms to compare (size, speed, etc.) or upgrade components instills confidence in the product since algorithm has been verified by independent compliance process

Texas Instruments DSP Algorithm Standard XDAIS introduced in 1999 (XDAIS = eXpressDSP Algorithm Interface Standard) as a means of helping product development as well as creating a rich marketplace of DSP algorithms eXpressDSP is not only a DSP algorithm standard, but also: Code Composer Studio IDE DSP/BIOS real-time OS Reference Frameworks – “skeleton” applications XDAIS specifies the “sockets” and “plugs” for the algorithms in this picture

XDAIS Requirements During standard development, the following were deemed to be the “guiding principles”: algorithms that originate from multiple vendors should be able to interoperate in the same system algorithms should be “framework-agnostic” – in other words, a given algorithm can be re-used in many different applications algorithm use should be possible in both static and dynamic environments (e.g. shared vocoders) algorithms can be delivered in binary form (which safeguards the vendor’s IP, and eliminates the user’s need to re-compile)

XDAIS Trade-off “There is no problem in computer programming that cannot be solved by an added level of indirection.”- M. Wilkes VS. “There is no performance problem that can’t be solved by eliminating a level of indirection.” – J. Gray So…. Adherence to the XDAIS standard must remain true to the spirit of DSP development – overhead must be minimized to preserve performance!

XDAIS Rules and Guidelines – SPRU352 The XDAIS standard consists of a set of 46 rules and 19 guidelines, each of which is defined at various algorithmic levels of abstraction. An algorithm must obey all of the rules in order to be eXpressDSP compliant. It is recommended that the algorithm also adhere to all guidelines but this is not required.

XDAIS Rules and Guidelines – SPRU352 The rules and guidelines at Level 1 are very high level and cover all application areas. all algorithms must be C-callable all algorithms must be re-entrant there must be no “hard-coded” data memory locations algorithms should attempt to use scratch memory in place of persistent memory algorithms must never directly access peripheral devices (use parameters)

Level 2 specifies an abstraction layer between the algorithm itself and the processor’s resources (such as memory, I/O, etc.). This ensures that multiple algorithms (or instances of the same algorithm) can co-exist on the DSP without “trampling” each other’s resources. Algorithm code should be partitioned into distinct sections and each section should be characterized by the average number of instructions executed per input sample. All algorithms must characterize their program memory requirements. All algorithms must characterize their worst-case interrupt latency for every operation. XDAIS Rules and Guidelines – SPRU352

Level 3 deals with specific vendors’ DSP families (e.g. TMS320C6000) - while concensus does not exist today, the guidelines in the standard at least provide a starting point. If a vendor deviates from this, it will be easy to draw attention to this in documentation. Algorithms should avoid the use of the float data type All C6x algorithms must be supplied in little-endian format Level 4 is specific to application domains and is NOT covered in the XDAIS standard. A DSP algorithm that meets the rules defined in levels 1-3 is considered eXpressDSP-compliant. XDAIS Rules and Guidelines – SPRU352

XDAIS provides a set of application programming interfaces (APIs) to enforce adherence to the rules, e.g. IALG (algorithm instance interface) – REQUIRED - responsible for creating an algorithm instance at run-time ensuring safe operation in any environment (static/dynamic or pre- emptive/non pre-emptive) - the most critical role performed here is that of memory management. All memory references in an algorithm must be directed through this API – no explicit memory references should exist in the code. IDMA2/ACPY2 APIs (direct memory access (DMA) interface) – - responsible for handling the DMA resource. - though not required, any eXpressDSP compliant algorithm that wants to use DMA must implement this interface, as well as the ACPY2 interface to request DMA services XDAIS APIs – SPRU360

Development Tools TI provides several development tools that assist in the implementation of XDAIS algorithms Documentation: Developer’s Kit (plugin to Code Composer Studio) Files required for XDAIS standard (header files, algorithm APIs and libraries, examples) eXpressDSP Component Wizard – automatically generate generic code for an algorithm interface (hides ugly details!) QualiTI algorithm validation tool – enables DSP engineers to automate the testing of their algorithm (for compliance, not functionality) TI document number Title (with comments) SPRU352TMS320 DSP Algorithm Standard Rules and Guidelines SPRU360TMS320 DSP Algorithm Standard API Reference SPRA581White Paper – The TMS320 DSP Algorithm Standard (general overview) SPRA810A Consumer’s Guide to Using eXpressDSP-Compliant Algorithms (for algorithm users) SPRU424TMS320 DSP Algorithm Development Guide (for algorithm producers)

Compliance Testing Responsibility to ensure that the conditions for eXpressDSP-compliance are met lies with the algorithm writer. The QualiTI tool is used for XDAIS compliance self-testing. The writer, after successfully passing QualiTI testing and examining the detailed report that is generated, submits the test result to TI (along with other relevant information such as processor platform, application area, etc.). Upon review by TI, the algorithm is then certified as eXpressDSP compliant and qualifies to use the logo It is interesting to note that at present, there are over 700 eXpressDSP compliant algorithms from roughly 100 third-party participants

ELG6163 Presentation Geoff Green March 20, 2006 TI Standard for Writing Algorithms