1 rules and guidelines, 2 requirements of the standard, Guidelines – Texas Instruments TMS320 DSP User Manual

Page 11

Advertising
background image

www.ti.com

1.1.1 Rules and Guidelines

1.2

Requirements of the Standard

Requirements of the Standard

Level 3 contains the guidelines for specific families of DSPs. Today, there are no agreed-upon guidelines
for algorithms with regard to the use of processor resources. These guidelines will provide guidance on
the dos and don'ts for the various architectures. There is always the possibility that deviations from these
guidelines will occur, but then the algorithm vendor can explicitly draw attention to the deviation in the
relevant documentation or module headers.

The shaded boxes represent the areas that are covered in this version of the specification.

Level 4 contains the various vertical markets. Due to the inherently different nature of each of these
businesses, it seems appropriate for the stakeholders in each of these markets to define the interfaces for
groups of algorithms based on the vertical market. If each unique algorithm were specified with an
interface, the standard would never be able to keep up and thus not be effective. It is important to note
that at this level, any algorithm that conforms to the rules defined in the top three levels is considered
eXpressDSP-compliant.

The TMS320 DSP Algorithm Standard specifies both rules and guidelines. Rules must be followed in
order for software to be eXpressDSP-compliant. Guidelines, on the other hand, are strongly suggested
recommendations that should be obeyed, but are not required, in order for software to be
eXpressDSP-compliant.

This section lists the required elements of the TMS320 DSP Algorithm Standard. These requirements are
used throughout the remainder of the document to motivate design choices. They also help clarify the
intent of many of the stated rules and guidelines.

Algorithms from multiple vendors can be integrated into a single system.

Algorithms are framework-agnostic. That is, the same algorithm can be efficiently used in virtually any
application or framework.

Algorithms can be deployed in purely static as well as dynamic run-time environments.

Algorithms can be distributed in binary form.

Integration of algorithms does not require recompilation of the client application, although
reconfiguration and relinking may be required.

A huge number of DSP algorithms are needed in today's marketplace, including modems, vocoders,
speech recognizers, echo cancellation, and text-to-speech. It is not possible for a product developer, who
wants to leverage this rich set of algorithms, to obtain all the necessary algorithms from a single source.
On the other hand, integrating algorithms from multiple vendors is often impossible due to incompatibilities
between the various implementations. In order to break this Catch-22, eXpressDSP-compliant algorithms
from different vendors must all interoperate.

Dozens of distinct third-party DSP frameworks exist in the telephony vertical market alone. Each vendor
has hundreds and sometimes thousands of customers. Yet, no one framework dominates the market. To
achieve the goal of algorithm reuse, the same algorithm must be usable in all frameworks.

Marketplace fragmentation by various frameworks has a legitimate technical basis. Each framework
optimizes performance for an intended class of systems. For example, client systems are designed as
single-channel systems with limited memory, limited power, and lower-cost DSPs. As a result, they are
quite sensitive to performance degradation. Server systems, on the other hand, use a single DSP to
handle multiple channels, thus reducing the cost per channel. As a result, they must support a dynamic
environment. Yet, both client-side and server-side systems may require exactly the same vocoders.

It is important that algorithms be deliverable in binary form. This not only protects the algorithm vendor's
intellectual property; it also improves the reusability of the algorithm. If source code were required, all
clients would require recompilation. In addition to being destabilizing for the clients, version control for the
algorithms would be close to impossible.

SPRU352G – June 2005 – Revised February 2007

Overview

11

Submit Documentation Feedback

Advertising