Reference Frameworks for expressdsp Software: A White Paper

Transcription

1 Application Report SPRA094A - December 2002 Reference Frameworks for expressdsp Software: A White Paper Steve Blonstein Texas Instruments, SDS ABSTRACT Reference Frameworks for expressdsp software are provided as starterware for applications that use DSP/BIOS and the TMS320 DSP Algorithm Standard (also known as XDAIS). Developers first select the Reference Framework that best approximates their system and its future needs. Developers then adapt the framework and populate it with expressdsp-compliant algorithms. As common elements such as device drivers, memory management, and channel encapsulation are already pre-configured in the frameworks, developers can focus on their system s unique needs and achieve better overall productivity. The Reference Frameworks contain design-ready, reusable, C language source code for TMS320C5000 and TMS320C6000 digital signal processors (DSPs). Developers can build on top of the framework, confident that the underlying pieces are robust and appropriate for the characteristics of the target application. This application report provides an overview of Reference Frameworks. Contents 1 Introduction Building a Cottage or a Castle? Characteristics of DSP Application Architectures Common Characteristics of Reference Frameworks Defining the Reference Frameworks Levels Elements of a Reference Framework Conclusion References List of Figures Figure 1. Elements of a Reference Framework List of Tables Table 1. Reference Framework Characteristics by Level expressdsp, DSP/BIOS, TMS320, TMS320C5000, and TMS320C67000 are trademarks of Texas Instruments. Trademarks are the property of their respective owners. 1

2 1 Introduction In 1999, Texas Instruments introduced several DSP software development capabilities that resulted in a dramatic improvement in the way our customers could develop software for the TMS320 family of DSPs. These key software elements are: Code Composer Studio Integrated Development Environment expressdsp Software Technology, which includes the following tightly knit ingredients that empower developers to tap the full potential of TI s DSPs: DSP/BIOS, a highly optimized, scalable, and extensible software kernel. TMS320 DSP Algorithm Standard, also known as XDAIS, which sets rules and guidelines for algorithm developers, greatly easing the burden on system integrators. A network of third-party suppliers, who provide hundreds of expressdsp-compliant algorithms. In addition, third parties also add value with expressdsp-compliant plug-ins for Code Composer Studio. While these elements have become well established in the marketplace, there are further opportunities to accelerate the software development process. The next opportunity TI has decided to address is the so-called framework space. Let s define the software framework as it pertains to a typical DSP software system: The framework is the glue that bolts together the application, XDAIS algorithms, and the underlying infrastructure. The infrastructure components manage system resources, allow hardware abstraction, handle input/output (I/O), and provide containers for algorithms. Despite the proliferation of DSPs beyond traditional telephony and communications applications, a relatively limited number of framework architectures are required to build most systems. It is this recognition that has allowed us to define and produce the new Reference Frameworks for expressdsp Software. These frameworks tie components together, but if the correct framework is used, it does not prevent the developer from adapting it to meet application requirements. A framework is often tuned to maximize or minimize specific key characteristics. For example, a compact framework provides a methodology for building compact, static systems with the smallest memory footprint possible. Tuning can optimize one or more parameters such as memory footprint size and processing cycles. In addition, application-specific tweaks may rely on the unique characteristics of a particular DSP and board. 2 Building a Cottage or a Castle? We ll borrow an analogy from the construction industry for a moment to explain the logic behind various decisions that went into defining the Reference Frameworks. When you build a cottage, simple materials such as wood and bricks are appropriate. The key design criteria are a small physical footprint, a limited number of rooms, and a low cost. But what if you re building a castle? The building materials and design criteria are radically different. The architects use very different approaches to the two projects. When was the last time you saw a moat and drawbridge on a cottage? That said, the projects still have common characteristics. Both structures probably use similar types of electrical supply and plumbing. And they both must meet industry-standard building codes. Code Composer Studio is a trademark of Texas Instruments. 2 Reference Frameworks for expressdsp Software: A White Paper

3 How does this building analogy translate to the DSP software world? The cottage DSP project is likely to be based on a low-cost TI DSP such as the TMS320C5401. This device offers 50 MIPS of performance with 8 K of internal memory for less than $4. A low-cost DSP, however, comes with challenges. How does one make the established components of the expressdsp infrastructure DSP/BIOS, XDAIS, and the Chip Support Library (CSL) work in such a constrained environment? Certain compromises need to be made. In the DSP world, compromises may include how deeply embedded the application must be, how many algorithms the system can run, and how many channels of data can be processed. At the other end of the spectrum, the next generation TMS320C64x devices provide thousands of MIPS of processing power and large internal and external memory blocks. Think of the castle here. Designers are looking for great flexibility so they can creatively embrace the power of the DSP. The number of algorithms used is likely to be both large and to change dynamically at run time. The numbers of processing channels may also be large. Though this design still leverages DSP/BIOS, XDAIS, and CSL, it is likely to do so in a quite different way than the cottage example. Just as the cottage and castle both use electrical and water supplies, both DSP applications use DSP/BIOS, XDAIS, and CSL. But, just as that castle is likely to need more sophisticated electrical and plumbing systems than the cottage, so does one DSP application need more flexibility and capacity than the other. 3 Characteristics of DSP Application Architectures We find that just six key characteristics are needed to determine the appropriate architecture for most systems. An important thing to note at this point is that architectural decisions are independent from end applications. For example, the software architecture for a two-channel voice coding system is almost identical to that of a two-channel MP3 decoder device and of a two-channel acoustic echo cancellation system. So let s consider these characteristics: 1. How many algorithms are used in the system? If only one or two are used, some basic techniques can be used to minimize the memory footprint. On the other hand, if many different algorithms are used or the set of algorithms used may change, then more sophisticated techniques are required to manage the algorithms. 2. How many channels of operation run in the system? Again, if there are one or two channels, certain assumptions and optimizations can be made. For a larger or more flexible number of channels, a more advanced approach is needed. 3. Does the system require dynamic object creation and resource allocation, or will static configuration suffice? By dynamic object creation, we mean that at run time, objects are created, run, and then deleted. This has implications for memory allocation. Dynamic systems typically allocate memory buffers on the fly using functions like the TMS320C64x is a trademark of Texas Instruments. Reference Frameworks for expressdsp Software: A White Paper 3

4 DSP/BIOS MEM_alloc() function. However, if the objects and functions used can be completely specified in advance, then the system can be statically pre-configured. Static configuration can be used to significantly reduce the system footprint multiple functions can be removed from the run-time image, thus saving precious on-chip program memory. 4. Will the system run at a single rate or multiple rates? It is important to look at the frame rates required by a system. In a simple system, all algorithms might run at 10 ms. In such systems, certain optimizations can be made. However, a multi-rate system might have one function running at 10 ms and another at ms. Such systems are more complicated. While they are well supported by DSP/BIOS, they require additional DSP/BIOS modules for correct operation. 5. Is system memory constrained? While DSPs with only 8 K or 16 K of internal memory are still used, plenty of new devices have hundreds of kilobytes of internal memory. There is always an important trade-off between functionality and memory footprint. If the footprint is tight, as in an 8 K system, the system footprint is paramount; functional compromises must be made. However, in a system with 256 K of internal memory, greater system flexibility may be desired at the expense of additional memory use. 6. Does the system need external control? If so, can communication be handled by a simple control thread or is a full-featured link required? For example, some systems contain a general-purpose processor (GPP), such as a PowerPC or MIPS. In such cases, how the DSP and general-purpose processor communicate is important. The framework should provide tools for such communication rather than requiring the developer to create protocols from scratch. Other systems use a simpler, low-priority control thread to allow an external processor (such as a host PC) to control aspects of processing. The answers to these questions tell us much about the type of system is being built, even though we don t know about the end application or the algorithms in the system. In theory, there are 2 6 (that is, 64) combinations of answers to these questions. However, only a few combinations are common. It is these common configurations that are to be addressed by Reference Frameworks for expressdsp software. 4 Common Characteristics of Reference Frameworks Before discussing the details of each Reference Framework, it is important to consider characteristics shared by all the frameworks: 100% C code. Reference Frameworks are written in 100% C code. As such, they are easy to modify. One can easily choose the modules that match system needs. Frameworks are designed to be easily ported to different target platforms and TI DSP generations. This is one of the long-term benefits of hardware abstraction using DSP/BIOS. Complete solutions. Each Reference Framework is provided as a complete solution. The caveat here is that the frameworks are populated with simple algorithms like FIR filters. Part of the strategy is to show how easily these simple algorithms can be replaced with more significant components. This is enabled through the TMS320 DSP Algorithm Standard, also known as XDAIS. 4 Reference Frameworks for expressdsp Software: A White Paper

5 Easy adaptation. Developers want to know how to quickly make the generic example application-specific without necessarily having to understand the low-level details of the system. This has been achieved through significant attention to the process for switching algorithms, adding channels, modifying drivers, and so on. Documentation. Users want details in terms of processing MIPS and footprint requirements. Great attention to detail has been expended to provide consistent and accurate representations of system costs across all frameworks. 5 Defining the Reference Frameworks Levels Categorizing the systems we see customers building in terms of the characteristics listed in section 3, shows that there is a need for between five and ten Reference Frameworks. Initially, we have defined the five Reference Framework levels shown in Table 1. Table 1. Reference Framework Characteristics by Level Design Parameter RF1 RF3 RF5 Static configuration Dynamic object creation (e.g., DSP/BIOS objects) Static memory management Dynamic memory allocation Number of channels 1 to 3 1 to 10 1 to 100 Number of expressdsp algorithms 1 to 3 1 to 10 1 to 100 Absolute minimum memory footprint Single-rate operation Multiple-rate operation Thread blocking Implements control functionality The following list describes these five Reference Frameworks: RF1 (Compact Framework). This framework is designed with the absolute minimum footprint possible, yet it retains all the elements of expressdsp. It is designed to use static object configuration and does not support run-time or dynamic object creation. Memory management is also completely static; dynamic memory management is not supported. The framework is optimized for a small number of channels and algorithms. Some flexibility is given up, but the reward is the absolute smallest footprint. In fact, the framework of an RF1 application can be as small as about 3.5 KW on a TMS320C54x platform. 1 1 Framework sizes include data and program memory for DSP/BIOS and CSL modules used, device drivers, the algorithm instantiation module, and any other framework glue. Reference Frameworks for expressdsp Software: A White Paper 5

6 There is no thread preemption or blocking at this level. Another limitation of this level is its single-rate operation. Also, no support is provided for a control thread or communication with a general-purpose processor. Digital hearing aids and low-cost Internet audio players are examples of applications that may use this framework. RF3 (Flexible Framework). The next level differs significantly from the first two levels. The biggest change is that the absolute minimum footprint is exchanged for flexibility. Compare the capabilities of RF1 and RF3 in Table 1. Though RF3 still supports only static object creation, support for dynamic memory management has been added. That is, data buffers can be configured and managed at run time. The added flexibility also allows more channels (typically up to 10) and more different algorithms (also typically up to 10) to be used. Another big difference is that RF3 supports multi-rate operation. This means different algorithms can run at different rates for example, one at a 10 ms frame rate and another at 20 ms. Finally, this level provides an additional thread that allows an external processor (such as a host processor) to control the DSP. As already mentioned, this flexibility comes at the price of a larger footprint. The framework size for a typical RF3 implementation is about 11 KW on a TMS320C54x platform. RF5 (Extensive Framework). This framework is for designers who are looking for extensive flexibility and are not overly concerned about system footprint. Like RF3, this framework supports static object creation and both static and dynamic memory management. It is architected to support hundreds of channels and algorithms, and allows both single-rate and multi-rate operation. Full thread preemption and blocking are enabled, as is a dedicated control thread. RF5 leverages more than 70% of the DSP/BIOS modules. Clearly, all this flexibility comes at a price in terms of system footprint. However, static configuration of DSP/BIOS modules keeps the footprint size small enough that applications based on RF5 are feasible on smaller C6000 and TMS320C55x devices. TMS320C54x, C6000, and TMS320C55x are trademarks of Texas Instruments. 6 Reference Frameworks for expressdsp Software: A White Paper

7 6 Elements of a Reference Framework Figure 1 shows the elements that make up a Reference Framework on the target DSP. Application Level Code Memory Mgmt & Overlays Framework Components Channel Abstraction expressdsp Alg. 1 expressdsp Alg. 2 Algorithm Manager DSP/BIOS Chip Support Library Device Driver Adapter Device Driver Controller TMS320 DSP Hardware Figure 1. Elements of a Reference Framework Let s examine the elements shown in Figure 1, starting from the bottom up: Device controller and device adapter. The device drivers used in Reference frameworks are based on a standard driver model, which provides device adapters and specifies a standard device controller interface. If you have unique external hardware, the device controller is likely to need customization, but the device adapter is likely to need little or no modification. A key point is that a framework is not tied to a particular device or driver model; there is a clean, logical separation between the application and the driver. Within the driver model, there is a clean, logical separation between the device adapter and the device controller. The value of a solid driver model is immeasurable. Without one, driver code may creep into the territory of the framework or application. This makes it impossible to separate the concerns of the device driver from the framework implementation when adapting the framework. Standard conventions for hardware drivers make integration and adaptation easier in much the same way that XDAIS simplifies algorithm integration. Reference Frameworks for expressdsp Software: A White Paper 7

8 Chip Support Library (CSL). The device controller uses Chip Support Library modules to support peripheral hardware. DSP/BIOS. This extensible software kernel is a good example of how each Reference framework leverages different amounts of the expressdsp infrastructure, depending on its needs. The low-end RF1 framework uses relatively few DSP/BIOS modules. In addition to providing an obvious footprint savings, reducing the number of modules helps clarify design choices for a designer who may not fully appreciate the ramifications of module selections. Framework Components. These elements are crafted to provide overall system resource management. One example of this is channel abstraction. Every Reference Framework needs some kind of channel management. But, design optimizations can be made based on knowledge of the number of channels likely to be in use. For simple systems with 1 to 3 channels, channel scheduling is handled with the low-overhead DSP/BIOS HWI and IDL modules. For larger numbers of channels, it is wiser to use the SWI module, although it comes with some extra footprint. For large systems with channels that change dynamically, the TSK module is most appropriate. In each Reference Framework, design decisions such as these let designers get systems running both more quickly and in the way most suited to the system. Similar to channel managers are the algorithm managers, which manage some number of expressdsp-compliant algorithms. Other framework components are modules that handle memory overlay schemes a critical technique in most memory constrained systems. Simply starting with the appropriate framework simplifies many choices that would need to be made when developing from scratch. expressdsp-compliant Algorithms. Each algorithm follows the rules and guidelines of the TMS320 DSP Algorithm Standard Rules and Guidelines (SPRU352). To be compliant with the standard, algorithms must not directly access any hardware peripherals and must implement standard resource management interfaces known as IALG (for memory management) and optionally, IDMA (for DMA resource management). In the examples that TI provides, the algorithms are generally simple ones like finite impulse response (FIR) filters and volume controllers. It is relatively easy to substitute more significant expressdsp-compliant algorithms for the TI-provided ones. It is this substitution that starts the process of making a generic Reference Framework application-specific. Application-level code. The last step is to modify the application-level code. This code applies unique and value-added application-specific knowledge, allowing for real product differentiation. Clearly the application code required for a single-channel MP3 player is quite different than that required for a digital hearing aid. 7 Conclusion Now that DSP/BIOS and XDAIS have been widely adopted, it makes sense to leverage that common base by providing quality design-ready frameworks for use as starterware. These Reference frameworks are 100% C source code, and are therefore highly portable and modifiable. Developers can use some or all of the appropriate Reference frameworks, as a basis for their applications. Any part that can be reused, as opposed to being written from scratch, provides significant advantages in terms of time-to-completion. 8 Reference Frameworks for expressdsp Software: A White Paper

9 8 References For additional information about Reference Frameworks, see and the following application notes: 1. TMS320 DSP Algorithm Standard Rules and Guidelines (SPRU352). 2. Reference Frameworks for expressdsp Software: RF1, A Compact Static System (SPRA791). 3. Reference Framework 3: A Flexible, Multi-Channel/Algorithm, Static System (SPRA793). 4. Reference Frameworks for expressdsp Software: RF5, Extensive High-Density System (SPRA795). 5. Reference Frameworks for expressdsp Software: API Reference (SPRA147). 6. Vocoders Integrated to RF3 (SPRA875). 7. MP3/AAC Player Implementation in RF3 (SPRA779). 8. Using an LIO-Based UART Driver in an RF3 Application (SPRA787). Reference Frameworks for expressdsp Software: A White Paper 9

10 IMPORTANT NOTICE Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections, modifications, enhancements, improvements, and other changes to its products and services at any time and to discontinue any product or service without notice. Customers should obtain the latest relevant information before placing orders and should verify that such information is current and complete. All products are sold subject to TI s terms and conditions of sale supplied at the time of order acknowledgment. TI warrants performance of its hardware products to the specifications applicable at the time of sale in accordance with TI s standard warranty. Testing and other quality control techniques are used to the extent TI deems necessary to support this warranty. Except where mandated by government requirements, testing of all parameters of each product is not necessarily performed. TI assumes no liability for applications assistance or customer product design. Customers are responsible for their products and applications using TI components. To minimize the risks associated with customer products and applications, customers should provide adequate design and operating safeguards. TI does not warrant or represent that any license, either express or implied, is granted under any TI patent right, copyright, mask work right, or other TI intellectual property right relating to any combination, machine, or process in which TI products or services are used. Information published by TI regarding third party products or services does not constitute a license from TI to use such products or services or a warranty or endorsement thereof. Use of such information may require a license from a third party under the patents or other intellectual property of the third party, or a license from TI under the patents or other intellectual property of TI. Reproduction of information in TI data books or data sheets is permissible only if reproduction is without alteration and is accompanied by all associated warranties, conditions, limitations, and notices. Reproduction of this information with alteration is an unfair and deceptive business practice. TI is not responsible or liable for such altered documentation. Resale of TI products or services with statements different from or beyond the parameters stated by TI for that product or service voids all express and any implied warranties for the associated TI product or service and is an unfair and deceptive business practice. TI is not responsible or liable for any such statements. Mailing Address: Texas Instruments Post Office Box Dallas, Texas Copyright 2002, Texas Instruments Incorporated