Texas Instruments TMS320 DSP manual Goals of the Standard, Intentional Omissions

Page 12

www.ti.com

Goals of the Standard

1.3Goals of the Standard

This section contains the goals of this standard. While it may not be possible to perfectly attain these goals, they represent the primary concerns that should be addressed after addressing the required elements described in the previous section.

∙Easy to adhere to the standard

∙Possible to verify conformance to standard

∙Enable system integrators to easily migrate between TI DSPs

∙Enable host tools to simplify a system integrator'stasks, including configuration, performance modeling, standard conformance, and debugging.

∙Incur little or no "overhead" for static systems

Although TI currently enjoys a leadership role in the DSP marketplace, it cannot directly control the algorithm software base. This is especially true for relatively mature DSPs, such as the C54xx family, where significant algorithm technology currently exists. Thus, for any specification to achieve the status of a standard, it must represent a low hurdle for the legacy code base.

While we can all agree to a guideline that states that every algorithm must be of high quality, this type of guideline cannot be measured or verified. This non-verification or non-measurement enables system integrators to claim that all their algorithms are of high quality, and therefore will not place a value on the guideline in this instance. Thus, it is important that each guideline be measurable or, in some sense, verifiable.

While this standard does define an algorithm'sAPIs in a DSP-independent manner, it does not seek to solve the DSP migration problem. For example, it does not require that algorithms be provided on both a C54x and a C6x platform. It does not specify a multiple binary object file format to enable a single binary to be used in both a C5x and a C6x design. Nor does it supply tools to translate code from one architecture to another or require the use of an architecture independent language (such as C) in the implementation of algorithms.

Wherever possible, this standard tries to anticipate the needs of the system integrator and provide rules for the development of algorithms that allow host tools to be created that will assist the integration of these algorithms. For example, rules related to algorithm naming conventions enable tools that automatically resolve name conflicts and select alternate implementations as appropriate.

Maurice Wilkes once said, "There is no problem in computer programming that cannot be solved by an added level of indirection." Frameworks are perfect examples of how indirection is used to "solve" DSP software architecture problems; device independence is achieved by adding a level of indirection between algorithms and physical peripherals, and algorithm interchangeability is achieved by using function pointers.

On the other hand, Jim Gray has been quoted as saying, "There is no performance problem that cannot be solved by eliminating a level of indirection." It is essential that the TMS320 DSP Algorithm Standard remain true to the spirit of the DSP developer: any overhead incurred by adherence to the standard must be minimized.

1.4Intentional Omissions

In this section, we describe those aspects of the standard that are intentionally omitted. This is not to say that these issues are not important, but in the interest of timeliness, this version does not make any recommendation. Future versions will address these omissions.

∙Version control

∙Licensing, encryption, and IP protection

∙Installation and verification (i.e., digital signatures)

∙Documentation and online help

Like all software, algorithms evolve over time, and therefore require version control. Moreover, as the TMS320 DSP Algorithm Standard evolves, older algorithm components may fail to be compliant with the latest specification. Ideally, a version numbering scheme would be specified that allowed host-based tools to automatically detect incompatible versions of algorithm components.

12

Overview

SPRU352G –June 2005 –Revised February 2007

Page 11 Page 13
Image 12
Page 11 Page 13
Contents Users Guide Rules and GuidelinesSubmit Documentation Feedback Contents Use of the DMA Resource Urls List of Figures Read This First Intended AudienceDocument Overview Related Documentation Text ConventionsRule n Guideline n Overview Scope of the Standard Rules for TMS320C5x Rules for TMS320C6xRules and Guidelines Requirements of the StandardGoals of the Standard Intentional OmissionsSystem Architecture FrameworksAlgorithms Core Run-Time SupportGeneral Programming Guidelines Use of C Language Threads and ReentrancyThreads RulePreemptive vs. Non-Preemptive Multitasking ReentrancyExample Data Memory Data MemoryMemory Spaces Scratch versus PersistentScratch vs Persistent Memory Allocation Algorithm versus Application GuidelineProgram Memory ROM-abilitySection Name Purpose Use of Peripherals Use of PeripheralsAlgorithm Component Model Interfaces and Modules Algorithms PackagingInterfaces and Modules Implementation Fir.hExternal Identifiers Naming Conventions Module Initialization and FinalizationModule Instance Objects Design-Time Object Creation Run-Time Object Creation and DeletionModule Configuration Example ModuleMultiple Interface Support Interface Inheritance SummaryElement Description RequiredAlgorithms AlgorithmsPackaging Object CodeHeader Files Debug Verses ReleaseModuleversvendorvariant.1arch Algorithm Performance Characterization Data Memory Program Memory Interrupt Latency Execution TimeHeap Memory ExternalSize Stack Memory Static Local and Global Data MemoryData Bss Object files Size Interrupt Latency Execution TimeMips Is Not Enough OperationExecution Time Model Execution Timeline for Two Periodic TasksProcess 19800059000 198000 Submit Documentation Feedback DSP-Specific Guidelines CPU Register Types Register TypesUse of Floating Point TMS320C6xxx Rules and GuidelinesEndian Byte Ordering Data ModelsRegister Conventions Status RegisterRegister Use Type CSR Field Use TypeInterrupt Latency TMS320C54xx Rules and GuidelinesProgram Models TMS320C54xx Rules and Guidelines Status Registers ST0 Field Name Use TypeST1 Field Name Use Type TMS320C55x Rules and Guidelines Stack ArchitecturePmst Field Name Use Type Relocatability ExampleSSP Status Bits ST2 Field Name Use TypeST3 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 SynchronizationAbstract Interface DMA GuidelineDMA Rule Resource Characterization Data Transfers bytes FrequencyAverage Maximum 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 GuidelinesMinimizing Logical Channel Reconfiguration Overhead Addressing Automatic Endianism Conversion IssuesInter-Algorithm Synchronization 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