Developing DSP code on converged hybrid DSP/RIS...

Recently processor designers have been reducing power consumption and part cost in a new way - by combining RISC and features into a single core, known as a ‘convergent’ processor core.  

Two examples of architectures that were designed from the beginning to be convergent are the Analog Deves Blackfin processor and StarCore processors (SC1000, SC2000, and SC v5). Some other examples of convergent architectures are based on well established RISC architectures and have been modified to efficiently fulfill DSP functions. These include the MIPS 24KE, Renesas SH3-DSP, PowerPC with AltiVec, and ARM966E-S.

Compared to standalone RISC syst, such convergent processors be much more efficient at performing DSP tasks. Yet compared to traditional DSP processor designs, convergent processors generally have more complex pipelines and can run at high enough speeds to allow for fast control-intensive computing.

But even with the design simplification and improvements in production costs and power usage such hybrid architectures can offer to the developer, programming can still be a chore. The choice of tools can make a huge difference in the ability to bring a product to market quickly that is maintainable, robust, and uniquely poised for the challenges a suessful product can bring.

For example, many of the DSP algorithms that can run on a converged processor have been written in assembly. Assembly programming provides the ultimate level of control over hardware and allows a clever programmer to squeeze every last drip of processing power out of a processor. As DSP applications get larger and more complex, the cost of programming in assembly consequently increases.

While it still may be useful to profile the DSP core and find the 20% of your code that takes 80% of the processing time and rewrite that code in assembly, the remainder of your code can be written in a higher level programming language.

Writing all DSP processing code in low-level assembly can slow down development and leave the product development team with a completely non-portable, confusing, unmanageable source base. The C language type system, run-time, and control-flow constructs greatly improves development time, ease of debugging, code browsing, and maintenance.

But the ISO C99 language standard still does not make provisions for operations commonly used in DSP applications, such as multiple-data operations, saturating arithmetic, or fixed point types. With a standard C compiler, an application could still be partitioned with control tasks written in C and DSP written in assembly.

One way tool vendors have improved this situation is to allow DSP programming in C by adding ‘intrinsic functions’ to their compiler. Intrinsic functions are recognized by name in the compiler and are hand differently than regular function calls in that the compiler will generate a known instruction or series of instructions, typically without making a function call at all.

For instance, an intrinsic function call might be used to signal to the compiler that a saturating add should take place on two integers. It would be called as if a function were written that takes two integral integer parameters (whose values should be added) and returns the result in an integer. For instance, if the instruction to perform a saturating add is ‘adds’ on the convergent architecture, the result of:

k = sat_add(i, j )

would simply be (assuming i, j, and k were in r1, r2, and r3 respectively):