SoCs: DSP World, Cores -> Platforms support multimedia SoC

The emerging applications space presents its own set of unique demands. The combination of diverse media (video, audio, data, speech, graphics) transported over ever wider pipes into interactive devices increases the performance requirements in all aspects of the electronics world.

The trend is toward integrating a number of multiple functions and numerous interfaces to maximize flexibility. And, in many markets, power is critical. Today's market also demands a clear path for product life cycle and evolution.

SoC is at a crossroads; the mainstream continues to believe that core-based design will prevail, but a different approach-platform-based design-is emerging. The key characteristic of this revolution is the shift from isolated components (processors, memories, AS SPs, ASICs) to integrated single-chip platforms.

Core-based design is faltering. Evidenced by an increasing number of IC design project failures, core-based design has become too expensive for semiconductor vendors and systems companies, making sense only for extremely high-volume parts such as the Sony Playstation. The only successful cores are programmable processors, memories and peripherals. Application-specific cores have short lifetimes because of the fast-paced market.

Even for successful cores, integration is still a major challenge. Overall, the industry is moving to platforms. Most platforms are "boards on chips." They duplicate the bus connection model. As yet, no one has put forward a compelling platform even for specific application areas. The industry press has latched on to the notion of "configurable platforms" or "programmable systems-on-chip."

Basically, a platform requires a task model with defined execution, communication (data and control), and concurrency as well as application to platform mapping methodology. Because a platform is already defined and ready for manufacturing, including verification suites, it provides rapid time-to-market.

Programmable on-chip resources mean that hardware resources do not need to be committed to a single function but can be reused for multiple functions. True parallel hardware and software development is possible because software can be developed independently of hardware implementation. A stable platform means that software development tools can ensure that software will run correctly. After an initial product has been delivered, the platform can be optimized for cost reduction, etc. without changes to software. Further, software can be updated to incorporate new features without changes to the underlying platform.

When considering multiple products, platforms provide a stable hardware target. The same masks are used across multiple projects (reprogrammed for different applications). Optimization and verification be nefit all product teams. Platforms provide a consistent architecture. The same platform is used across different product configurations (e.g., different channel densities). Platforms provide a common design environment and allow software component reuse across products.

The platform approach represents a revolution in ASIC development. ASIC development changes from hardware design to a combination of application software development and platform configuration. The development of an ASIC can be done by application specialists (rather than hardware specialists), enabling higher levels of creativity and innovation in systems.

About 95 percent of current IC/ASIC EDA tools move into platform development and implementation tools. Designers will now be using application development (software), platform mapping and platform configuration tools.

Platforms should provide four key characteristics: performance, programmability, scalability/integration and configurability.

Performance issu es in multimedia SoC include concurrent execution and multitasking. A platform should handle true parallel execution of tasks. There are many aspects of platform programmability that should be considered. And, creation and use of testbenches are important to development. And, there are issues from integration and configurability standpoints that need to be addressed.

Here are some platform options and characteristics:

• Roll your own. Creating your own platform allows you to use specifically selected blocks and custom logic. In this scenario, the user has to manage integration of nonstandard blocks into the bus and the user must custom-design concurrent communication. Examples of this approach include ASIC backplanes and on-chip bus standards.

• Customizable platforms. Customizable platforms offer another alternative. These platforms are 80 percent complete and provide programmable logic or base array for rapid integration of custom logic. The disadvantages associated with cu stomizable platforms are that the platform is fairly limited in terms of scalability and configurability, silicon efficiency is somewhat low, and verification of the integrated logic can be risky.

• Application-specific platforms. Application-specific platforms are targets for a particular application domain (e.g. video). They provide some limited programmability along with hard-coded application accelerators. They lead to plug-in products for meeting reference system characteristics. The disadvantages of application-specific platforms lie in the relative lack of flexibility, especially in I/O and hardware functions. Examples of this kind of platform are media processors such as Philips' Nexperia, Equator MAP and network processors such as C-Port and SiliconSpice.

• Programmable platforms. Programmable platforms provide a high degree of configurability/programmability. They can support a wide range of applications by incorporating a series of scalable, configurable processors and programm able I/O. They offer a high degree of support for product evolution. The disadvantages are the overhead that comes with the high degree of programmability (instruction memories, processor controllers), the threshold on functionality, and unused on-chip resources. Examples of this technology are Improv's PSA, Cradle, and Sun Microsystems' MAJC.

Multiple levels of configurability are possible for platforms. These include the macro structure of the platform-such as the number of processor cores, interconnects between cores-the I/O capabilities and resources, the characteristics of the individual processors, and addition of user-defined accelerators.

A high degree of configurability allows the designer to tailor available resources to application needs. It permits streamlining of data and instruction memory, optimization using custom processors and accelerators, and matching I/O to system requirements.Configurability allows customizing the platform to the specific needs of an application do main. The designer can evaluate the number of processors, sizes of memories and I/O makeup. It will be possible to configure different characteristics to address performance, die size or power considerations. Designers can add accelerators for critical application functions.

Conversely, a platform can be "deconfigured" to include just the resources needed for a particular application. Programmable I/O modules may be hardwired.

On a macro-structure level, it is possible to define processor macrostructure and configuration, to select the number and type of processors to include, and to customize processors to a particular application domain.

Further, the type and size of each instruction and data memory can be adapted, as well as defining external memory access and protocol. Selection of integration models for external components is possible, along with choosing the number and type of I/O modules to include. Capabilities include configuring I/O modules with parameters such as FIFO depth s and state machines controlling data movement.

Central to any platform implementation is a processor core. And a number of options are available:

• Traditional RISC/DSP. Characterized by one operation per instruction. These typically fall in the 10- to 300-Mips range for processing power. In terms of power consumption, typical metrics are 50 Mips/W (Oak Teak) to 11.2 Mips/W (ARM9). One of the more valuable aspects of these cores is that a library of software solutions is readily available. They also produce relatively small code size across applications. Examples of this technology come from ARM Ltd. (Cambridgeshire, U.K.), MIPS Technologies Inc. (Mountain View, Calif.), DSP Cores, Tensilica Inc. (Santa Clara, Calif.), and ARC Cores Ltd. (London).

• Superscalar/VLIW. These technologies provide a "fine-grain" parallelism in the form of multiple operations per instruction (i.e. per clock cycle). Typical performance figures are 800 Mips (TI C6201 at 200 MHz) and 1.3 Bops (Impro v Jazz at 100 MHz). Power consumption for the Improv Jazz is 130 Mips/W. Superscalar architectures allow dynamic (on-chip) allocation of operations to resources. Superscalar offers an existing compiled software base, simple compilation (at the expense of complex hardware), and smaller instruction width with larger decoding hardware. ZSP is an example of a superscalar architecture. VLIW (very long instruction word) architectures function with static (compiler) allocation of operations to resources. They offer simple hardware at the expense of a complex compiler, and larger instruction width with smaller decoding hardware. Examples of VLIW technology are Improv's Jazz, the C6x from Texas Instruments (Dallas), and the StarCore from the partnership of Lucent Technologies (Murray Hill, N.J.) and Motorola Inc. (Schaumburg, Ill.).

• Pseudo-ILP/Hybrid-ILP. This technology provides some limited instruction-level parallelism (ILP) coupled with more traditional processing. One approach to achieving this is to use RISC with occasional VLIW to accelerate critical loops/blocks. In this instance, the VLIW portion is typically hand-coded by an application developer. Examples of this approach are the REAL from Philips Semiconductors (Sunnyvale, Calif.) and the Carmel from Infineon Technologies (San Jose, Calif.). Both achieve limited ILP by issuing one instruction to multiple processors (SIMD).

Configurability needs

There is a growing awareness of the need for configurable processors. In the past two years there have been a number of new commercial entries in this space including RISC/DSP such as ARC Cores and Tensilica as well as VLIW such as Improv's Jazz, Philips' REAL and the STMicroelectronics (St. Genis, France) and Hewlett-Packard Co. (Palo Alto, Calif.) alliance.

Different aspects of the processor can be made configurable. A key feature is the ability to add user-defined logic and opcodes into the datapath. This addresses the processor's performance weaknesses on irregular algorithmic sections and allows the user to redefine common operations for specific domain.

The ability to add user-defined opcodes means the designer can add and subtract opcodes from existing computation units. Unique to VLIW is the ability to control the number of operation slots per instruction, the allowing of overlapped opcodes, and reducing computation unit overhead with instruction compression.

User-defined accelerators are another key feature of configurable processors. These can be used to accelerate critical functions in algorithms. They can address functions such as data manipulation (masking, etc.), data representation (bit widths, saturation, rounding), and other custom logic operations. Similar approaches include ARC's user-defined extensions and Improv's DDCU's (designer defined computation units).

Designing for SoC today requires different development methodologies for hardware, software and communication. Custom SoC design and implementation is expensive, long, compl ex and unpredictable. It calls for multiple expensive EDA tools and front-end and back-end design. What is more, system integration and IC design complexity means more than one pass at mask generation and manufacturing.

There are a number of potential technology paths for SoC design. Behavioral synthesis is one approach. Here algorithmic issues and search space preclude efficient conversion of behavioral code to RTL. Additionally, deep-submicron requires an increasing knowledge of physical implementation during design.

Another approach is core-based design. Unfortunately, this path offers a long time-to-market, is expensive (custom mask set, verification, IP licensing, etc.) and fraught with legal, business, technical and competitive issues. Heterogeneous modeling and mapping is a third route. It requires early commitment hardware/software tradeoffs, and implementation choices are limited by the selection of the modeling technique.

Finally, the platform approach offers a technology pa th for SoC design. It provides for separation of function (application) from implementation (platform). Application development is performed using a structured semantic model. Platform development is done independently. The platform approach calls for a new set of tools that include application development environments, "mapping" tools and platform analysis and configuration tools.

Configurable platforms allow for new and powerful application development methodology. They can be based on an intuitive semantic model. Heterogeneous modeling requires different tools, different target implementations, etc. A common semantic model enables a new set of integrated system-level development tools-development tools, verification tools and platform mapping tools.