Customized DSP -> Use-specific theme takes new shape in DSPs
Use-specific theme takes new shape in DSPs
By Henry Davis, EE Times
March 12, 2001 (2:14 p.m. EST)
URL: http://www.eetimes.com/story/OEG20010312S0083
The semiconductor industry is in the midst of perhaps its biggest change since the transition from a handful of transistors on a single die to the first fledgling steps of larger-sale integration. Companies are providing technology access at all levels of design. From a black box that implements a specific digital signal-processing function to complete access to the internals of a complex DSP processor design, DSP technology is becoming available to nearly every engineer developing DSP products.
While digital signal processing doesn't lead this impending technology shift, nowhere are the effects of the move to an intellectual-property model more keenly felt than in DSP.
For more than 15 years companies like Analog Devices, Lucent, Motorola and Texas Instruments have held the keys to applications that need signal-processing power. For the most part, these companies have held their architectures close to the vest and controlled the instruc tion-set architectures with absolute authority. In part, they achieved that control by engaging with other, selected companies that met stringent applications and business standards.
Permitting customer engineers access to the crown jewels of DSP processor internals can be a scary proposition, and one that carries risk for both the supplier and the customer. But many companies have sprung up offering access to DSP technology. That technology ranges from microcontrollers with DSP capabilities to highly architected, high-performance DSP engines. The companies are as varied as their technology offerings. Articles in this week's section illustrate that trend. The mainstream DSP suppliers have joined the approach as well after more than a decade of carefully orchestrated development of customized DSPs for individual customers.
Ray Simar, TI's chief architect on its C6x DSP, says the key to successful DSP design is working from the application in, rather than from the core out. |
DSP cores are available in a number of forms. At first glance it's tempting to classify cores according to the way in which they are delivered. Soft cores are delivered as synthesizable hardware-description language (HDL) models, while hard macros are delivered as a physical layout intended for a specific semiconductor process. Meanwhile, firm macros employ some physical-layout elements combined with soft elements. But those distinctions fall far short of telling the whole story.
Hard, soft and firm macros classify intellectual-property designs, also called virtual components, according to the implementation techniques that are available to the engineer. A more informative classification relies on the essen tials of the architecture and the degree of access provided to that architecture. At one end of the spectrum are the microprocessor designs, typically RISC based, that incorporate some DSP functionality. For these products the emphasis is on control algorithms, C-programming support and code density trade-offs. DSP functions tend to be secondary in importance. Also, because the DSP capabilities are grafted onto a RISC processor, the products often have compromises on the DSP side that limit performance for multiple memory accesses per cycle.
On the other end of the DSP core spectrum are the architectures developed specifically to perform DSP operations. For raw performance in signal processing it's hard to replace a purpose-designed DSP. But flat-out performance on signal-processing algorithms comes at a price. DSPs are notoriously poor targets for C compilers, resulting in bloated code.
In addition, the special-purpose hardware created to speed signal-processing algorithms makes it nearly im possible to generate efficient code. Consequently, in practice, the blazingly fast DSPs only achieve their performance potential when hand coded in assembly language. To add insult to injury, many high-performance DSPs often perform only moderately well on programs that involve logic control. To be sure, there are exceptions-but mostly these architectures are limited to the very newest high-end DSPs, which are not yet available as cores.
There's an old engineering adage that goes "small, fast, cheap-choose any two." The same can be said of price, performance and power. For years companies have focused on engineering a standard product and then forcing it to fit applications-some would say that the application is squeezed into the standard product. But that is changing.
Texas Instruments' Fellow Ray Simar offers an applications-centric view of DSP. According to Simar, the key to successful DSP design lies in working from the application in, rather than from the core out.
That point of view may seem the antithesis of TI's DSP strategy. But DSP core design, like DSP chip-level design, cannot be separated from the system needs of the application. In Simar's approach, fundamental architectural decisions are increasingly based on end-equipment requirements, so that DSP core design has now become more application-oriented than ever.
It's tempting when discussing DSP technologies to focus on the DSP issues to the near exclusion of all else. But Motorola's Tan Dao and Joseph Gergen say there's more to systems cost than just the DSP. That brings into focus the question of developing DSP software in C. Dao and Gergen are the architecture development manager and lead architect, respectively, on Motorola's DSP568XX chip family. An efficient instruction-set architecture for both the compiler and the hand-code assembly can be a critical component of the overall system cost, they argue.
An easy-to-use optimizing compiler reduces development time and cost-two of the most critical compone nts of the development cycle. In most embedded systems, the memory modules dominate the overall die size. In these cases a good trade-off is to increase the core size and complexity to achieve an efficient ISA. However, this must be weighted against the very low-cost system, where memory content is smaller.
Argy Krikelis, chief technology officer of Aspex Technology, proposes that single-instruction, multiple-data (SIMD) DSPs may become the preferred approach to achieving very high performance. The programming limitations of very long instruction word (VLIW) processors with high-level languages require engineers to use very low-level assembly programming or precoded functions to achieve high performance. This type of programming requires specialized knowledge of the hardware architecture-often extremely complex in VLIW processor designs. By contrast, the SIMD model assumes a number of processing elements, each executing exactly the same sequence of instructions on their local data. The key advantages are a reduction in overall hardware complexity, design regularity, the enhancement of computing resources and a simplified path to software development. .
Engineers developing DSP-based products need not rely solely on standard products. There are now many companies that offer a wide range of options technically-and from the business perspective. It's possible to find the ideal fit for a particular application regardless of the criteria used to make the selection. There are literally dozens of DSP core choices from as many companies.
If virtual components are your choice, there is a good selection of alternatives. If a specific instruction set is your goal, that can be achieved as well-and not necessarily from the originator of the instruction set. No matter what your application, deciding on the criteria for selecting your next DSP processor helps you sort through the alternatives.
Related Articles
- Customized DSP -> Parallel DSPs: speed at a price
- Customized DSP -> Wider DSPs enrich comms design
- The Next-Generation Cellular Network Takes Shape
- Optimizing High Performance CPUs, GPUs and DSPs? Use logic and memory IP - Part II
- DSPs with PCI Express interface extend connectivity while improving performance and power efficiency
New Articles
Most Popular
E-mail This Article | Printer-Friendly Page |