Texas Instruments TMS320 DSP manual Module Configuration, Example Module

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

Submit Documentation Feedback