Texas Instruments TMS320 DSP 用户手册

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.

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

SPRU352G – June 2005 – Revised February 2007