Earlier this month The Mathworks announced embedded C code generation capability for its popular MATLAB tool, which is widely used for digital signal processing algorithm design. According to The Mathworks, the new Embedded MATLAB capability is intended to enable MATLAB users to generate efficient C code directly from MATLAB source code files for use in embedded applications. Embedded MATLAB supports a subset of the
By enabling automatic translation of MATLAB algorithm implementations to C, Embedded MATLAB will help bridge the gap from algorithm development to embedded software implementation. But engineering managers hoping to cut costs may be disappointed: Embedded MATLAB will not replace skilled software engineers.
Over the past 20 years, MATLAB has come into widespread use among digital signal processing algorithm developers. Many engineers get their first exposure to MATLAB in undergraduate engineering courses. MATLAB is a natural choice for DSP algorithm developers because its M language, based on matrices, is well suited for expressing many types of DSP algorithms. And as an interpreter-based (rather than compiler-based) environment, MATLAB facilitates rapid experimentation. In addition, MATLAB’s default use of double-precision floating-point data types means that algorithm developers can, in many cases, ignore finite-precision effects that might otherwise complicate their work.
In a typical digital signal processing system development environment, algorithm developers design, test, and refine algorithms using MATLAB with floating-point data types. Then they hand their M code to embedded software developers, who are tasked with quickly creating correct, efficient and maintainable software implementations of the algorithms for a specific fixed-point embedded processor. As shown in Figure 1, the usual first step in that process is to manually translate the algorithms from M to floating-point C. (This is the step that Embedded MATLAB is intended to eliminate.) Next, the floating-point C code is typically converted to fixed-point C code. (This conversion is a little-understood and much under-appreciated craft.) Then, the developer can begin optimizing the fixed-point code to achieve good performance on the selected target processor.
Figure 1. Typical process for adapting MATLAB algorithm reference code for an embedded processor.
This development process has some well-known problems, not the least of which is that manual translation of an algorithm from one language to another can be time-consuming and error prone. And, often, just when the software developers have finished optimization, the algorithm designers will come up with a new and improved algorithm, so that the cycle must be started anew.
Given these difficulties, generation of embedded software from high-level DSP algorithm representations has been a goal of tools companies and researchers for at least 20 years. In fact, start-up Catalytic Inc. has been offering MATLAB-to-C capabilities for several years. But despite many attempts to address the problem, very little embedded digital signal processing software today is generated directly from high-level algorithm representations. Most is written by software engineers, using a combination of C and (for performance-critical blocks) assembly language. We expect that this will continue to be the case for the foreseeable future. Embedded C code generation from MATLAB will be valuable for many organizations, but it is not—and is not intended to be—a complete solution to the creation of embedded signal processing software.
One key reason why MATLAB-to-C is not a complete solution for embedded DSP software stems from the fact that algorithms and embedded software are very different things. When algorithm designers are devising algorithms, they’re focused on the algorithm. Appropriately, they tend to concentrate on getting the correct numbers out of the algorithm. But when those algorithms are implemented in software, the software developers have a different set of design decisions to make. These may include choice of data types, data organization and buffering, latency, timing, and use of parallel processing capabilities, to name just a few. Such decisions must be made carefully in order to obtain efficient software. Since algorithm developers typically aren’t much concerned with such considerations, the M code they write does not embody thoughtful design decisions in these areas. And it is not realistic to expect a code translation tool to make those design decisions automatically. As a result, a code translation tool can be part of the solution, but shouldn’t be expected to replace the know-how of skilled software engineers.
An example of this can be seen in the realm of data types. Although MATLAB does have fixed-point capabilities, algorithm developers typically use MATLAB’s default double-precision floating-point data types, as mentioned above. Using a translation tool, floating-point M code will be translated into floating-point C code. But if the target is a fixed-point processor (as it usually is), it still remains for the embedded software developer to migrate the algorithm from floating-point C code to fixed-point C code. For all but the most trivial algorithms, this is a demanding part of the design process: it can take as long to migrate an algorithm to an efficient fixed-point representation as it took to develop the algorithm in the first place.
Another important aspect of M-to-C translation is that it supports only a subset of the M language and function libraries. As a result, efficient use of the translation capability will require engineers to change the way they write M code. One simple but significant example of this is that MATLAB dynamically allocates memory to support arbitrary array sizes as needed. Use of M-to-C translation, however, requires that array sizes be declared statically.
Embedded MATLAB can reduce some of the grunt work associated with translating from M-to-C, but will not eliminate the need for skilled software engineers to design and implement efficient embedded software. As with any tool, the key to successful use is in understanding its capabilities and limitations.
Add new comment