Texas Instruments TMS320 DSP manual Algorithms, Core Run-Time Support

Page 14

www.ti.com

System Architecture

1.5.2 Algorithms

Careful inspection of the various frameworks in use reveals that, at some level, they all have algorithm components. While there are differences in each of the frameworks, the algorithm components share many common attributes.

∙Algorithms are C callable

∙Algorithms are reentrant

∙Algorithms are independent of any particular I/O peripheral

∙Algorithms are characterized by their memory and MIPS requirements

In approximately half of the frameworks reviewed, algorithms are also required to simply process data passed to the algorithm. The others assume that the algorithm will actively acquire data by calling framework-specific, hardware-independent, I/O functions. In all cases, algorithms are designed to be independent of the I/O peripherals in the system.

In an effort to minimize framework dependencies, this standard requires that algorithms process data that is passed to them via parameters. It seems likely that conversion of an "active" algorithm to one that simply accepts data in the form of parameters is straightforward and little or no loss of performance will be incurred.

Given the similarities between the various frameworks, it seems possible to standardize at the level of the algorithm. Moreover, there is real benefit to the framework vendors and system integrators to this standardization: algorithm integration time will be reduced, it will be possible to easily comparison shop for the "best" algorithm, and more algorithms will be available.

It is important to realize that each particular implementation of, say a speech detector, represents a complex set of engineering trade-offs between code size, data size, MIPS, and quality. Moreover, depending on the system designed, the system integrator may prefer an algorithm with lower quality and smaller footprint to one with higher quality detection and larger footprint (e.g., an electronic toy doll verses a corporate voice mail system). Thus, multiple implementations of exactly the same algorithm sometimes make sense; there is no single best implementation of many algorithms.

Unfortunately, the system integrator is often faced with choosing all algorithms from a single vendor to ensure compatibility between the algorithms and to minimize the overhead of managing disparate APIs. Moreover, no single algorithm vendor has all the algorithms for all their customers. The system integrator is, therefore, faced with having to chose a vendor that has "most" of the required algorithms and negotiate with that vendor to implement the remaining DSP algorithms.

By enabling system integrators to plug or replace one algorithm for another, we reduce the time to market because the system integrator can chose algorithms from multiple vendors. We effectively create a huge catalog of interoperable parts from which any system can be built.

1.5.3 Core Run-Time Support

In order to enable algorithms to satisfy the minimum requirements of reentrancy, I/O peripheral independence, and debuggability, algorithms must rely on a core set of services that are always present. Since most algorithms are still produced using assembly language, many of the services provided by the core must be accessible and appropriate for assembly language.

The core run-time support includes a subset of HWI functions of DSP/BIOS to support atomic modification of control/status registers (to set the overflow mode, for example). It also includes a subset of the standard C language run-time support libraries; e.g., memcpy, strcpy, etc. The run-time support is described in detail in Appendix B of this document.

14

Overview

SPRU352G –June 2005 –Revised February 2007

Page 13 Page 15
Image 14
Page 13 Page 15
Contents Users Guide Rules and GuidelinesSubmit Documentation Feedback Contents Use of the DMA Resource Urls List of Figures Document Overview Read This FirstIntended Audience Rule n Related DocumentationText Conventions Guideline nOverview Scope of the Standard Rules for TMS320C5x Rules for TMS320C6x Rules and Guidelines Requirements of the StandardGoals of the Standard Intentional OmissionsSystem Architecture FrameworksAlgorithms Core Run-Time SupportGeneral Programming Guidelines Threads Use of C LanguageThreads and Reentrancy RulePreemptive vs. Non-Preemptive Multitasking ReentrancyExample Data Memory Data MemoryMemory Spaces Scratch versus PersistentScratch vs Persistent Memory Allocation Algorithm versus Application GuidelineSection Name Purpose Program MemoryROM-ability Use of Peripherals Use of PeripheralsAlgorithm Component Model Interfaces and Modules Algorithms PackagingInterfaces and Modules Implementation Fir.hExternal Identifiers Module Instance Objects Naming ConventionsModule Initialization and Finalization Design-Time Object Creation Run-Time Object Creation and DeletionModule Configuration Example ModuleMultiple Interface Support Element Interface InheritanceSummary Description RequiredAlgorithms AlgorithmsPackaging Object CodeHeader Files Debug Verses ReleaseModuleversvendorvariant.1arch Algorithm Performance Characterization Data Memory Program Memory Interrupt Latency Execution TimeSize Heap MemoryExternal Stack Memory Static Local and Global Data MemoryData Bss Object files Size Mips Is Not Enough Interrupt LatencyExecution Time OperationExecution Time Model Execution Timeline for Two Periodic Tasks59000 198000 Process198000 Submit Documentation Feedback DSP-Specific Guidelines CPU Register Types Register TypesEndian Byte Ordering Use of Floating PointTMS320C6xxx Rules and Guidelines Data ModelsRegister Use Type Register ConventionsStatus Register CSR Field Use TypeProgram Models Interrupt LatencyTMS320C54xx Rules and Guidelines TMS320C54xx Rules and Guidelines ST1 Field Name Use Type Status RegistersST0 Field Name Use Type Pmst Field Name Use Type TMS320C55x Rules and GuidelinesStack Architecture Relocatability ExampleSSP ST3 Field Name Use Type Status BitsST2 Field Name Use Type Homy TMS320C24xx Guidelines GeneralTMS320C28x Rules and Guidelines TMS320C28x Rules and GuidelinesXAR0 M0M1MAP Use of the DMA Resource Submitting DMA Transfer RequestsOverview Algorithm and FrameworkRequirements for the Use of the DMA Resource Logical ChannelData Transfer Properties Data Transfer SynchronizationDMA Rule Abstract InterfaceDMA Guideline Average Maximum Resource CharacterizationData Transfers bytes Frequency Runtime APIs Strong Ordering of DMA Transfer RequestsSubmitting DMA Transfer Requests Device Independent DMA Optimization GuidelineCache Coherency Issues for Algorithm Producers 13 C6xxx Specific DMA Rules and GuidelinesSupporting Packed/Burst Mode DMA Transfers 14 C55x Specific DMA Rules and GuidelinesInter-Algorithm Synchronization Minimizing Logical Channel Reconfiguration OverheadAddressing Automatic Endianism Conversion Issues Non-Preemptive SystemPreemptive System Algorithm B Algorithm a Inter-Algorithm Synchronization Appendix a General Rules Performance Characterization Rules DMA RulesGeneral Guidelines DMA Guidelines Submit Documentation Feedback DSP/BIOS Run-time Support Library Core Run-Time APIsDSP/BIOS Run-time Support Library TI C-Language Run-Time Support LibraryBibliography BooksSubmit Documentation Feedback Glossary Glossary of TermsGlossary of Terms Glossary of Terms Important Notice
Top Page Image Contents