Reusable architecture is DSP framework

As a result, a new category of programmable DSPs appeared in the market, referred to as application-specific programmable DSPs, which were customized to better perform on a specific task or application, while maintaining programmability (for example, the TriMedia and Equator for video applications). The drawba ck is that such a solution is not cost-effective in other areas, so more hardware has to be added in order to offer a competitive platform.

This article discusses the significance of reusing a single DSP architecture for different applications and market segments, and the benefits it offers to DSP users, and suggests a DSP architecture concept that meets the various requirements imposed by different users.

Given the ever-increasing demand for performance, speed and low power consumption, the life cycle of programmable DSPs is declining, and switching to new DSP architectures becomes a more frequent practice. In the past, companies underestimated investments related to acquiring and adopting a new DSP technology. Whether one selects an ASSP-based DSP or a DSP core in an intellectual-property (IP) format, the investment is far greater than the per-chip or the IP-licensing cost.

At the outset, the DSP of choice is part of a total solution. Assuming an IP DSP core is being used, this core must be integrated into a system-on-a-chip, including a set of peripherals, memories, a system interface and so on. While some of these could be easily reused for a newer DSP core, by leveraging on standard bus connectivity, others would require a redesign, sometimes from scratch.

For example, a memory controller is usually very dependent on the specific processor. Thus, it significantly differs from one processor to the other. Such a memory controller could include sophisticated multichannel DMAs, a cache controller and a memory-management unit. Other tightly coupled peripherals and accelerators would surely require a design from scratch, as they interface with the DSP in a very distinct manner.

Porting the software to a new DSP is a major development task that should be carefully considered. A DSP already deployed by a company has all the software components installed in place. Developing the entire software framework for a new DSP from scratch is a long and arduous task, even while using a highly optimized C compiler. Another investment related to software porting is the process of learning the software development tools that complement the DSP. The knowledge of the integrated development environment in general and of the compiler optimization techniques in particular should be rebuilt with minimum reusability. Buying some of the software components from a third-party vendor or using a translator from one DSP to another may shorten that task but will be as costly as developing it by oneself.

The learning curve for the hardware designers, the system engineers and the DSP software developers must be assessed and translated to man-years of investment. The growing awareness of these investments is the main trigger for requirements for DSP technology reuse.

DSP technology reuse
As companies try to leverage on existing products and technologies for next-generation products and applications, the trend toward technology reuse is intensifying. If a company has greatly inves ted in a particular DSP technology for a specific product, why not leverage on this investment for the next-generation product? Moreover, would it be possible to reuse the same DSP for an entirely different application?

For example, consider a large semiconductor conglomerate, developing and manufacturing different products and appliances, from wireless handsets to ADSL gateways and home entertainment appliances. No doubt, these are very different markets requiring very diverse processing demands. It would be very cost-effective to conceive that the same DSP platform would fit all the different products. Could a single investment in DSP technology be leveraged and reused across varying product lines?

The reuse of DSP technology depends on the level of programmability. It is not uncommon in the industry to come across ASIC developers who prefer a hardwired solution instead of a programmable one. That is pertinent to various applications, especially low-end applications trying to go for the fin al cost-reduction phase, or for high-end applications where flexibility is an important requirement.

The trend toward software-programmable DSPs is evident given the ever-changing standards of telecom and multimedia markets, and the exponentially increasing cost of silicon respin in 0.13-micron technologies and beyond; both issues can be addressed by utilizing the same DSP platform (and in some cases, the same chip) for next-generation products. However, a single DSP architecture could not provide the level of flexibility required to support both a mobile platform and an HDTV solution running H.264, the latest multimedia standard.

One possible solution is to offer a powerful general-purpose DSP that could fit into many applications. This would enable the customer to commit to a single DSP architecture and reuse it for different products. The disadvantage of this concept is the level of suitability of such a processor to different requirements. It obviously cannot be optimized for diverse and sometimes even conflicting constraints.

Yet, another innovative solution for reducing DSP switching costs is in the form of an architecture framework. This new concept is based on a single architecture, out of which multiple DSP designs can be extracted. Each DSP design can fit a different market with varying processing requirements and different operational points in terms of speed, power consumption and die size. The architecture learning curve, including the software development tools and the system interface and peripherals, can be reused across all DSP designs. Such architecture enables the reuse of any software components previously developed for a new DSP design in the same architecture framework.

As an example, the CedarDSPCore, the sixth-generation DSP core from ParthusCeva, is based on the concept of such an architecture framework. This framework is wide enough to support various processing demands, from a two-multiply-accumulate DSP design up to an eight-MAC DSP. The core can eithe r process 16-bit or 32-bit native data word sizes. The level of parallelism supported is also variable, as are the memory subsystem structure and the system interface. All the different variations are supported with a single architecture.

Another important feature of DSPs today is the ability to extend the instruction set according to new standards requirements. A base architecture is fixed in place, while new instructions and their related hardware can be customized, ensuring that such a DSP will continue to serve the needs of new, forthcoming algorithms.

This flexibility brings some cost. From the architecture viewpoint, the DSP has to dedicate some of its encoding space for such future extensions. The outcome is a smaller encoding space for the base instruction-set architecture, and more limited computational capabilities. Other sacrifices of an extendable architecture are dedicated ports to the register files and other indications, not used by the nonextended DSP designs. From the develop ment tools point of view, an extendable DSP requires high flexibility. User-defined instructions need to be supported by the full tool chain, including the compiler, simulators and binary tools.

The table provided suggests different DSP designs based on the CedarDSPCore architecture framework, each matching a specific application.

Each DSP design can be further tuned to meet an operational point. The trade-off among speed, die size and power consumption is straightforward when dealing with an IP core. Each DSP design can be synthesized and implemented by the customer according to his needs.

In summary, the life cycle of a DSP is relatively short, as companies are continuously looking for more powerful processors, with more computational capabilities and higher speeds. Switching from one DSP architecture to another entails a huge cost, related to the learning curve associated with the hardware, software and system views of the DSP. In order to break the cycle of buying and adopting a n ew DSP architecture for every new application or the ever-increasing processing demands, a multipurpose architecture framework is recommended, where multiple DSP designs can cohabit, each DSP design addressing specific market needs.

Eran Briman is director of DSP architecture at ParthusCeva Inc. (San Jose, Calif.).

See related chart

See related chart