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

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

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

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

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

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

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

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

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

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

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

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

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

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

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