Inside DSP on Tools: Software Building Blocks for Signal Processing Applications

Evolving software demands
Off-the-shelf software building blocks are increasingly popular for a number of reasons. Perhaps the most important reason is that both signal processing applications and the processors that run them are becoming more complicated. At the same time, engineering teams are shrinking at many companies. These factors make it more difficult for development groups to create all of the software for an application on their own.

In addition, as signal processing technology proliferates into a growing range of application areas, many development groups that lack specialized expertise in DSP software need to incorporate signal processing functionality into their products. In some cases—particularly when signal processing is a minor component of the product—it is better to buy the signal-processing technology than to hire or train signal processing specialists.

Increasing time-to-market and cost pressures are additional factors, particularly for the growing number of signal processing applications targeting consumer markets. These pressures push designers to use off-the-shelf components to reduce development time, cost, and risk.

Last but not least, many products are based on standards. It is typically difficult to implement these standards in ways that differentiate the product. This is particularly true for applications based on well-established standards. For example, highly optimized G.7xx voice codec implementations are available for a broad range of processors. It is hard to create a new codec implementation that has a significant advantage—such as smaller memory footprint—over these existing implementations. “Reinventing” such commoditized components is a poor use of limited engineering resources. Instead, companies increasingly focus their efforts on aspects of the product where there is room to gain an advantage. For example, a company might be able to devise a post-processing filter that makes the output of the G.7xx codec sound better.

Potential pitfalls

Off-the-shelf software building blocks can provide many benefits, but they also have many potential drawbacks. A key problem is that the software may not match the application needs. As a simple example of this, there are many types of filters. The filter functions included in a library of building blocks might not be the right kind of filter for your application.

Getting various software building blocks to work together can also present serious challenges. In some cases, the processor vendor provides a “framework” to ease integration, but even then integration requires more than just snapping components together. We discuss this topic further at the end of the article.

It can also be difficult to get accurate information about the quality and performance of the available software building blocks. This is a significant problem because much of this software comes from small companies with limited track records—which makes it hard to know what quality to expect. The issue of quality is particularly critical for newer application areasf and for applications where new standards have been introduced. Software for these applications is typically less mature and therefore more likely to be buggy or poorly optimized.

Customer support can also be a stumbling block. When a problem arises, the software vendor may be slow to respond or unable to resolve the issue. And when a problem crops up in integration, it may not be obvious which software component is to blame. To make matters worse, the small companies selling signal processing software sometimes are acquired, shift their business focus, or go out of business—and any of these moves can cause them to cease supporting their earlier products.

Challenges can also arise for companies attempting to develop their own reusable software components. This is particularly true for larger companies, where there are multiple development groups with little interaction. A key challenge for companies developing their own software components is finding the right balance between completing the current product quickly at minimum cost and investing enough time and effort to create widely reusable components.

Function libraries

Function libraries (also referred to as algorithm libraries) are collections of software implementing common, computationally intensive signal processing algorithms. Example algorithms that might be part of a function library include filters and transforms. Typical applications incorporate many signal processing algorithms—often a dozen or more—as well as a large amount of supporting code (for example, supervisory control code). Typically, only a subset of the algorithms will be available from function libraries, and none of the supporting code will be available from libraries. Hence, function libraries can only be used for a small portion of the code in most applications.

Although function libraries may only be useful for a small fraction of the code in an application, they can often eliminate a large fraction of the overall programming effort. This is because optimization of key algorithms often consumes a large share of the total programming resources in a project. In most signal processing applications, a handful of algorithms comprise the vast majority of the processor’s workload. As an example of this, Figure 2 illustrates the contributions of several key algorithms to an application’s total code size and execution time. In general, such algorithms must be carefully optimized in order to meet performance targets. This can be difficult, time-consuming work. Hence function libraries with the right algorithms can save a lot of programming work.

Fortunately, it is often possible to find library functions that are useful for the application at hand. One reason for this is that many different kinds of applications use the same kinds of signal processing algorithms (for example, many applications use filtering algorithms). As a result, the basic functions found in many libraries are useful for a broad range of applications. In addition, some libraries provide functions for a specific class of applications. For example, a library might target audio applications. Another strength of function libraries is that they are widely available. Processor vendors that target signal processing applications almost always provide free libraries of basic signal-processing functions. Some third-party vendors also sell function libraries.

Unfortunately, it is not always easy to tell whether a given library function will meet the requirements of a particular application. For one thing, seemingly similar functions can behave quite differently. For example, two filter functions may handle overflow conditions in different ways. Seemingly similar functions may also make different tradeoffs in areas such as speed, memory use, and flexibility. For example, one FIR filter function may allow an arbitrary number of filter taps, while another filter may restrict the number of taps. If the system designer chooses the wrong functions—or if a suitable function cannot be found—it may be necessary to tweak the functions before using them in the application. It is often possible to tweak function libraries, because these libraries are generally provided as assembly language source code. But re-working the functions reduces the time-to-market and cost benefits of using off-the-shelf code.

Usually, a given function library can be used only with a particular processor family. However, a few libraries do support multiple architectures. The most notable example is the Intel Performance Primitives (IPP) library. Intel provides several versions of this library that support various x86- and XScale-based processors. Another notable exception is the Numerix SigLib library, which is available both as ANSI C code and as binary code for a variety of processors. In addition, the Khronos standards organization is working on OpenMAX, a standardized application programming interface (API) for calling signal processing functions on a wide variety of hardware.

Application components

Although function libraries can be helpful, system developers can gain larger benefits from using larger software building blocks. Not surprisingly, off-the-shelf application components—software blocks that perform major tasks such as compressing audio—have become increasingly popular in recent years.

An application usually contains several components. For example, the software for a video conferencing system might include voice codecs, video codecs, a user interface, an IP protocol stack, and an OS. And just as some algorithms are used in many applications, certain application components are used in a wide range of applications. Codecs for voice, audio, and video processing are particularly commonplace. The G.7xx voice codecs mentioned earlier are good examples of this. For such codecs, a system designer may be able to obtain off-the-shelf implementations from a wide range of vendors. For newer or less popular codecs, there may be few choices. Also, implementations of newer codecs tend to be less thoroughly optimized.

Some applications include large amounts of non-signal-processing functionality. For such applications, non-signal-processing software components can be critical. OSs are a particularly prominent example of this. Obtaining an OS from a third party—rather than building a proprietary OS—can save a system developer a significant amount of time and effort. Unfortunately, system designers using DSPs generally have only a few off-the-shelf OS choices. In contrast, general-purpose processors are typically supported by a wide range of OSs.

If everything goes well, using off-the-shelf application components can greatly reduce the time and cost of system development. However, the use of off-the-shelf components carries significant risks. Application components are fairly large, complex pieces of code. As a result, it is often difficult for a system designer to judge the quality and performance of a component until the system designer receives the code. Even after receiving the code, verifying the quality and performance of the code can require extensive testing. In addition, application components are often provided as object code, so the system designer cannot modify the components. This also increases the difficulty of getting different components to work together.

Reference designs

In some cases, system developers want to write as little of the code as possible. For example, a system designer may have expertise in low-cost manufacturing techniques but have little knowledge of software. In such cases, system designers can benefit from using reference designs.

A reference design is a complete, working system that integrates the key software and hardware components needed for a particular type of product. As one example, Freescale provides a variety of reference designs for motor control applications. As shown in Figure 3, Freescale’s motor control reference designs typically include motor control software, a DSP, power electronics, and a motor. More generally, reference designs usually include printed circuit board designs, software, and documentation.

Some reference designs are intended to serve as starting points that system designers can use as a basis for their own products. Other reference designs are “production-ready”—in other words, the reference design can be transformed into a finished product with little design effort. In either case, the obvious benefit of a reference design is the potential for dramatically reduced development time and effort. However, reference designs pose large risks. Because a reference design represents a large portion of the finished product, the performance, cost, and other characteristics of the finished product are highly dependent on the characteristics of the reference design. This is particularly true if the system designer is not an expert in the application—which is likely to be the case.

 

Reference designs are available from most major processor vendors; a few third-party vendors also provide reference designs. Due to the cost and effort required to create reference designs, these packages are available mainly for a few high-volume applications.

In addition to the function libraries, application components, and reference designs we have discussed, there are other types of software building blocks not covered in this article. For example, there is a level between reference designs and application components which might be called the “subsystem” level.

Putting it Together

As mentioned earlier, it can be difficult to get different pieces of off-the-shelf software to work together—or to work with in-house software. To address this problem, some processor vendors, such as LSI Logic and Texas Instruments, provide coding standards. These standards specify coding conventions that reduce conflicts between different pieces of code. For example, the standards specify naming conventions to prevent name-space conflicts. The standards also specify APIs that allow abstraction of the memory system and peripherals. This makes it easier to use the same code in applications with different memory or peripheral configurations.

A few vendors have also begun providing “frameworks.” A framework provides an application template that developers can drop their own code (or third-party code) into. A framework typically includes an OS, device drivers, and an overall software architecture for certain class of application. For example, one framework might be designed for simple, low-cost applications, while another might be designed for complex, multi-channel applications. Because a framework does not target a specific application, a framework is unlikely to be optimal for any given application. However, frameworks can speed development by eliminating the need to code basic, commonplace portions of the application. Examples of frameworks include Texas Instruments’ Reference Frameworks and CEVA’s Xpert-Creator Software Framework.

Building towards the future

The trends pushing system developers to use software building blocks are likely to continue. Signal processing applications are likely to become more complicated even as system developers are forced to work with fewer engineering resources. As a result, software building blocks will become an increasingly important part of the development process. Indeed, it will become more common for system designers to choose a processor based on the availability of appropriate software. For processor vendors, this presents an opportunity to differentiate their offerings. It will present vendors with a challenge, as they will have to field a growing amount of software. For system developers, a key challenge will be finding ways to evaluate vendors’ complex, unfamiliar software.