Texas Instruments TMS320 DSP manual Module Configuration, Example Module

Page 30

www.ti.com

Interfaces and Modules

Guideline 4

All modules that support object creation should support run-time object creation.

Note that the eXpressDSP-compliant algorithms are a special type of module. When we define algorithms below, we will see how algorithms support run-time object creation. The guideline above is intended to cover modules such as those that make up the core run-time support as well as the eXpressDSP-compliant algorithms.

3.1.7 Module Configuration

In an ideal world, a module that implements an API can be used in any system that requires the API. As a practical matter, however, every module implementation must make trade-offs among a variety of performance metrics; program size, data size, MIPS, and a variety of application specific metrics such as recognition accuracy, perceived audio quality, and throughput, for example. Thus, a single implementation of an API is unlikely to make the right set of tradeoffs for all applications.

It is important, therefore, that multiple implementations of the same API be well supported by any eXpressDSP-standard development framework. In addition, each module has one or more "global configuration" parameters that can be set at design time by the system integrator to adjust the behavior of the module to be optimal for its execution environment.

Suppose for example, that one created a module that implements digital filters. There are several special cases for digital filters that have significant performance differences; all-pole, all-zero, and pole-zero filters. Moreover, for TI architectures, if one assumes that the filter'sdata buffers are aligned on certain boundaries the implementation can take advantage of special data addressing modes and significantly reduce the time required to complete the computation. A filter module may include a global configuration parameter that specifies that the system will only use all-zero filters with aligned data. By making this a design-time global configuration parameter, systems that are willing to accept constraints in their use of the API are rewarded by smaller faster operation of the module that implements the API.

Modules that have one or more "global" configuration parameters should group them together into a C structure, called XYZ_Config, and declare this structure in the module'sheader. In addition, the module should declare a global structure named XYZ of type XYZ_Config that contains the module'scurrent configuration parameters.

3.1.8 Example Module

This section develops a very simple module to illustrate the concept of modules and how they might be implemented in the C language. This module implements a simple FIR filter.

The first two operations that must be supported by all modules are the init() and exit() functions. The init() function is called during system startup while the exit() function is called during system shutdown. These entry points exist to allow the module to perform any run-time initialization necessary for the module as a whole. More often than not, these functions have nothing to do and are simply empty functions.

void FIR_init(void)

{

}

void FIR_exit(void)

{

}

The create entry point creates and initializes an object; i.e., a C structure. The object encapsulates all the state necessary for the other functions to do their work. All of the other module entry points are passed a pointer to this object as their first argument. If the functions only reference data that is part of the object (or referenced within the object), the functions will naturally be reentrant.

typedef

struct FIR_Params {

/* FIR_Obj

creation parameters */

int

frameLen;

/*

input/output frame length */

int

*coeff;

/*

pointer to

filter coefficients */

} FIR_Params;

FIR_Params FIR_PARAMS = { 64, NULL }; /* default parameters */

30

Algorithm Component Model

SPRU352G –June 2005 –Revised February 2007

Page 29 Page 31
Image 30
Page 29 Page 31
Contents Users Guide Rules and GuidelinesSubmit Documentation Feedback Contents Use of the DMA Resource Urls List of Figures Read This First Intended AudienceDocument Overview Rule n Related DocumentationText Conventions Guideline nOverview 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 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 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 Element Interface InheritanceSummary 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 Mips Is Not Enough Interrupt LatencyExecution Time OperationExecution Time Model Execution Timeline for Two Periodic TasksProcess 19800059000 198000 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 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 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