5 system architecture, 1 frameworks, Architecture – Texas Instruments TMS320 DSP User Manual

Page 13: Frameworks

Advertising
background image

www.ti.com

1.5

System Architecture

ALG

ALG

ALG

Framework

Status

Cmd

Status

Cmd

Core run time support

1.5.1 Frameworks

System Architecture

To support the ability of a system integrator to rapidly evaluate algorithms from various vendors, a
mechanism should be defined that allows a component to be used for evaluation only. This would
encourage algorithm vendors to provide free evaluations of their technology. It is important to provide
mechanisms, such as encryption of the code, that protect the vendor's IP; otherwise, vendors will not
make their components readily available.

Each algorithm component is typically delivered with documentation, on-line help files, and example
programs. Ideally, this set of files would be standardized for each algorithm, and installation into the Code
Composer Studio environment would be standardized. The standardization will greatly simplify the rapid
evaluation and system integration process. In addition, it is important that when a component is obtained,
its origin can be reliably determined, to prevent component theft among algorithm vendors.

Many modern DSP system architectures can be partitioned along the lines depicted in

Figure 1-2

.

Figure 1-2. DSP Software Architecture

Algorithms are "pure" data transducers; i.e., they simply take input data buffers and produce some number
of output data buffers. The core run-time support includes functions that copy memory, and functions to
enable and disable interrupts. The framework is the "glue" that integrates the algorithms with the real-time
data sources and links using the core run time support, to create a complete DSP sub-system.
Frameworks for the DSP often interact with the real-time peripherals (including other processors in the
system) and often define the I/O interfaces for the algorithm components.

Unfortunately, for performance reasons, many DSP systems do not enforce a clear line between algorithm
code and the system-level code (i.e., the framework). Thus, it is not possible to easily reuse an algorithm
in more than one system. The TMS320 DSP Algorithm Standard is intended to clearly define this line in
such a way that performance is not sacrificed and algorithm reusability is significantly enhanced.

Frameworks often define a device independent I/O sub-system and specify how essential algorithms
interact with this sub-system. For example, does the algorithm call functions to request data or does the
framework call the algorithm with data buffers to process? Frameworks also define the degree of
modularity within the application; i.e., which components can be replaced, added, removed, and when can
components be replaced (compile time, link time, or real-time).

Even within the telephony application space, there are a number of different frameworks available and
each is optimized for a particular application segment (e.g., large volume client-side products and low
volume high-density server-side products). Given the large number of incompatibilities between these
various frameworks and the fact that each framework has enjoyed success in the market, this standard
does not make any significant requirements of a framework.

SPRU352G – June 2005 – Revised February 2007

Overview

13

Submit Documentation Feedback

Advertising