Cut DSP Development Time

Cut DSP Development Time – Get High Performance From C, No Assembly Required

Designers are asking their DSP cores to do more and more of the heavy workloads required for highly complex algorithms for filtering, FFT, MIMO, and other signal processing intensive applications. To get high performance from a conventional DSP core, developers have traditionally used assembly code programming, which is time consuming and difficult to debug.

Advances in state-of-the-art DSP architectures and companion compilers now make it possible for developers to keep their algorithms in C and still get the performance they need from a general-purpose high-performance DSP.

The magic is in the compiler technology. This white paper explains how Tensilica's ConnX D2 DSP engine coupled with the advanced Tensilica XCC compiler can help you get equivalent or better performance using standard C than other DSPs programmed in assembly code. The result:  you can get your project finished much faster.

DSP software developers have traditionally converted key performance-critical portions of their algorithms to assembly language because that was considered the only way to achieve high performance when using a DSP core. Every DSP architecture is different - optimized for a different type of data throughput challenge - and programmers need to understand each underlying DSP architecture in order to optimize the code manually using assembly coding techniques.  Thus specialized knowledge is required to achieve effective results.

Assembly programming also locks code into a specific DSP platform by targeting that DSP's specific instruction set architecture (ISA). The company loses flexibility in choosing cores for future projects that need to reuse code.

Most developers use C to quickly create and test software. Why haven't they been staying in C, the language that the algorithm was probably developed in?

The answer is simple. Most C compilers cannot efficiently map algorithms to DSP instruction sets aimed at accelerating targeted algorithms.  If the amount of code that needs precise tuning is small, assembly coding can be an acceptable solution.  But as application programs have become larger and more complex and as the number of industry standards has multiplied over the years, the need for a purely C-based solution has escalated.

How can the usage paradigm move from an assembly-level to a C-code level?  Let's first examine the most common first step in that evolution  - the use of C intrinsics.

Using Intrinsics in C Code for Performance

Because most C compilers can't take full advantage of high-performance DSP architectures, intrinsic instructions can be used within C to represent assembly instructions. A compiler maps the intrinsic instructions to specific DSP core instructions, but only uses those special functions when the intrinsics are used in the code. Otherwise, the compiler falls back to a default implementation provided by the language run-time environment. Intrinsics have proven popular for specific applications areas, such as the ITU-T/ETSI modules in voice codec algorithms.

The use of intrinsic functions is certainly an improvement over being required to write all DSP code in assembly, but it does have limitations. First, by using an intrinsic function the code is most likely no longer fully portable, unless a full C function equivalent is provided by the compiler vendor. Further, intrinsic functions names for the same logical function are not the same in different architectures, thus requiring significant recoding for portability.

Second, an intrinsic function's name may not be the best possible match to what that function does. Therefore, code management with extensive documentation is required to answer the question - now what does that function do again? It's easy to get confused and challenging to make sure programmers are using the proper intrinsic for the exact function required.