A design chain for embedded systems - Computer - Semantic Scholar

0 downloads 0 Views 1MB Size Report
units that deal with each other at arm's length. With the rise of ... hardware-software architectures that speed the ... example, the embedded processor IP house of ...
EMBEDDED COMPUTING

A Design Chain for Embedded Systems Grant Martin and Frank Schirrmeister, Cadence Design Systems

T

oday’s embedded systems design culture produces custom products from scratch. However, as electronic products become more complex and global competition demands shorter time to market, the industry is moving toward a design process that integrates commodity system-on-chip (SoC) platforms. How do we go about developing such integration-oriented SoC design flows and evolving a new platformbased design culture?

THE ELECTRONIC DESIGN CHAIN It all starts with the electronic design chain. This methodology has emerged over the past few years to address the increasing complexity of SoC design. Figure 1 shows the process for supply chain management in the design of integration-oriented embedded platforms. The design chain links providers of both hardware and software virtual components, or intellectual property (IP) blocks, to systems houses that develop products for end-user applications. This process ultimately links to the traditional or outsourced manufacturing and distribution supply chain, and hence to the consumer. Of course, in vertically integrated companies, the design chain may be internal. Over the past several years, however, vertically integrated companies have tended to split into distinct units that deal with each other at arm’s length. With the rise of fabless semiconductor companies, pure-play foundries, IP companies, and systems houses, all elements of the design chain become dis100

Computer

form types. Today we can distinguish four types, ranging from full-application to fully programmable platforms. Note, however, that boundaries between these types can blur as providers expand their reach. For example, independent processor providers like MIPS and ARM are adding more application-specific hardware and software to their platforms and moving closer to the space of full-application platforms.

The electronic design chain addresses the increasing complexity of SoC design.

tinct business entities seeking to establish appropriate design relationships. Platforms are a mechanism for accelerating the design chain process. They provide preintegrated, preverified collections of IP blocks, organized into hardware-software architectures that speed the development of end-user products. They also accelerate the exchanges involved in design. For example, the embedded processor IP house of today will become a creator of preverified processor-centric platform subsystems. A fabless semiconductor company with a Bluetooth product today may decide to create a licensable platform subsystem for electronic design providers who wish to integrate it with other IP blocks or virtual components. For systems houses or semiconductor houses building application-specific standard products or final products, these platform-level components represent a powerful means for accelerating design. They also add reuse-driven efficiency to the design chain.

A FLEXIBLE RANGE OF PLATFORM TYPES The evolution of platform-based design has given rise to different plat-

Full-application platforms Platforms that let derivative-product designers create complete applications on top of hardware-software architectures represent one end of the spectrum for platform-based design. These fullapplication platforms typically include a library of hardware modules in a variety of configurations. Derivativeproduct designers choose among the modules to build, for example, complex dual-processor architectures with hierarchical bus systems tailored to a specific product’s requirements. They can also choose application-specific hardware, such as function accelerators, if required. A layer of firmware and driver software separates the hardware-specific sections of the platform from middleware and application software. These sections are exposed to the derivativeproduct designer, who can develop differentiating software IP independent from the detailed hardware architecture. Platform providers can optimize the hardware for cost, energy consumption, or size while keeping it independent from the application by providing a configurable application programming interface (API) to the derivative-product designer’s software.

Examples of full-application platforms are Philips Semiconductors’ Nexperia, Texas Instruments’ Open Multimedia Applications Platform (OMAP), ARM’s PrimeXsys, Infineon’s MGold Platform, and Intel’s Xscale Architecture.

IP block providers (ICs and operating systems)

Processor-centric platforms Typically centered on specific processors, these platforms focus on the software access to a processor. Using them to model complete applications often requires adding specific hardware elements. The consumer can also choose from different real-time operating systems (RTOSs). Key software services are made available through software libraries. Examples include the ARM Micropack, ST Microelectronics ST100, and Motorola StarCore platforms.

Communication-centric platforms These platforms typically give consumers a communication fabric optimized for a specific application domain. These fabrics are often bundled with specific processors but are usually meant to be generic, which allows all modules developed in compliance with these busses to be reused easily in the appropriate platforms. The platform consumer must add components to design a complete application. Examples include the Sonics µNetwork, Palmchip CoreFrame, IBM CoreConnect, and ARM AMBA bus architectures.

Fully programmable platforms Adding programmable logic to the platform allows consumers to customize it using both hardware and software. At one end of the possibilities in fully programmable platforms are those similar to processor-centric or full-application platforms but with embedded reconfigurable logic; semiconductor companies such as LSI Logic have licensed reconfigurable logic fabrics for this purpose (for example, Adaptive Silicon). At the other end of the spectrum, traditional field-programmable gate array

Semiconductor houses (with fabrication facilities)

Semiconductor houses (without fabrication facilities)

Pure-play foundries

Systems houses

Original equipment manufacturers

IP block providers (applications and middleware)

Figure 1. The embedded SoC provider-integrator design chain. What used to be a vertically integrated process within each product company has become significantly fragmented. Platform-based design can accelerate the flow in this chain.

(FPGA) providers are adding hardcoded processors to their programmable logic products. Prominent examples are the Altera Excalibur platform including Nios and ARM cores and the Xilinx Vertex II Platform-FPGA incorporating one or more PowerPCs. Triscend and Chameleon also offer platforms that focus on the software issues. Chameleon’s solutions, for example, can switch between complete applications within one clock cycle, providing a whole new set of challenges to the software operating these platforms.

PLATFORM USER TYPES We can also distinguish three types of platform users. Depending on the particular application, a systems house might choose, for example, to adopt a catch-up approach when it is new to a product domain. In this case, it could use a complete package approach to create a derivative product that it can introduce into the market quickly. If the systems house leads the market, however, it will no doubt want to ensure product differentiation through the power designer or platform differentiator approaches.

Power designers Power designers bring significant design expertise and resources to bear

on product differentiation at both the hardware and software levels. Starting with a base platform—for example, a processor-centric platform—they select IP blocks from platform libraries to meet specific application requirements. Where the library is inadequate, or where they can differentiate through developing their own custom components, they will do so—at some cost in design time and risk. Power designers emerge in application areas where the market has divided into a commodity market for basic products and a high-end niche market that wants the maximum in application power and flexibility and is willing to pay for it. Semiconductor houses often choose a power designer to guide the original platform development.

Platform differentiators Differentiators are interested in the middle ground between high performance and higher risk. They use a platform to meet an application requirement and develop specific software for it. In addition, they select virtual components from platform libraries for hardware blocks that can accelerate application performance. These designers want product differentiation but at relatively low risk and short design time. March 2002

101

Embedded Computing

Table 1. Design chain for TI’s Open Multimedia Applications Platform.* Design chain component

OMAP infrastructure

Suppliers

IP block providers

Hardware IP Software IP

ARM DSP BIOS, Linux, Microsoft WinCE and Pocket PC 2002, OSE, Palm OS, Symbian SDK and OS (EPOC) AM Road Electronics, Atelier, Chanceux, General Packet Radio Service (GPRS) software, GeoVector, Microsoft, PacketVideo, ProSense Technology, Real Networks, TI Security Library, Ultima Electronics OMAP Acer, Ericsson, Nokia, Sony, TI for Handspring In addition to TI partners (above), Acer Communications & Multimedia, Ares Communications, Arima Communication, ASUSTeK Computer, Chi Mei Communications Systems, Compal Communications, FIC, GVC, High Tech Computer, Inventec, LG Electronics, McubeWorks, Mitac-Synnex, Palm, Quanta Computer, Sendo, ZTE, DBTel, Quanta, Tecom, TelePaq Technology, Universal Scientific Industrial

Applications and middleware Semiconductor houses Systems houses

TI TI partners Device and equipment manufacturers

*Derived from Texas Instruments press releases for OMAP at http://www.ti.com/sc/docs/products/.

Complete package designers These designers will expect a platform provider to offer a mostly complete solution in both hardware and software. They want rapid time to market and are willing to trade design cost, nonrecurring engineering costs, and differentiation from possible competitors also using the platform in return for the lowest risk and quickest design time. Software is the primary means of product differentiation. Reconfigurable hardware logic allows some differentiation in hardware, again at low risk. End product programmability is key.

EXAMPLE PLATFORM: OMAP The Open Multimedia Applications Platform from Texas Instruments delivers voice and multimedia-enhanced applications for 2.5G and 3G wireless phones, personal digital assistants (PDAs), and advanced mobile Internet appliances. The OMAP application processor is a dual-core architecture based on the TMS320C55 digital signal processing core and a TI-enhanced ARM microcontroller. The OMAP design chain also includes • Software IP. OMAP supports several RTOSs to suit different application-domain requirements, user 102

Computer

preferences, and legacy code. • Application and middleware providers. Ported applications and middleware are crucial to the OMAP strategy. The platform includes applications like MPEG4 decoding, positioning, and audio playback. A partnership with PacketVideo offers access to media content. • Development partners. From the earliest announcements of OMAP development, TI has partnered with key users of the final platform. TI itself announced plans to use OMAP in a commercial design that adds capabilities to the Handspring PDA product line. • Device and equipment manufacturers. A variety of customers have endorsed OMAP, announcing intended or actual use of it in their end applications. • Development centers. The OMAP developers’ network now includes several companies, and TI has announced cooperation with others. This cooperation will generate new tools to accelerate the development of future applications for wireless device users. A full-application platform like OMAP engages participants through-

out the design chain: semiconductor companies, systems houses, software developers, and hardware-software IP providers.

FUTURE TRENDS In the future, it will be feasible to extend platform-based design beyond mass-production consumer markets — such as wireless handsets and set-top boxes—into more performancedemanding areas of the wired communications infrastructure. These include base stations and network processing devices, starting at the edge of the network and moving into the core. The concept of a network processor unit (NPU) core is an area for possible platform development. Network processors have provoked considerable interest over the past two years but have not yet established themselves as the inevitable better alternative to custom application-specific integrated circuits (ASICs). Significant issues of performance, architectural stability, software development environments, and software reuse are associated with NPU options. We can postulate, however, that a few basic NPU architectures will succeed in the marketplace over the next two years. Starting with a legacy software base and reasonable development environ-

ment, the next logical step will be to create NPU-based platforms, in which more of the architecture—in both the hardware and software domains—is defined, integrated, and verified. The platform will include key in-system communications architectures and onchip memories, as well as interface peripherals optimized for the network application. When these platforms emerge, sometime in the next five years, the NPU-centric platform subsystem will have arrived. Design practice in these domains will then shift from the current custom ASIC approach to the heavy reuse-centric platform-based approach. There is also an industry trend toward fully or highly programmable platforms with fixed custom processor cores, on-chip memory and communications structures, and a large component of reconfigurable logic. This trend originates from two distinct sources: • a combination of custom platforms, with some limited amount of reconfigurable logic; and • FPGA vendors adding custom control processors to their reconfigurable logic devices. Reconfigurability is a key capability to provide application flexibility, and these platforms combine the advantages of a custom processor for software with a multiapplication reconfigurable fabric to allow large production runs and lower costs. The issues with these reconfigurable approaches center around two key questions: • How much reconfigurability is sufficient for a platform to offer differentiation and rapid design change to many users and applications within a domain? • Will the highly programmable platforms be cost-effective as a delivery vehicle for mass-production consumer areas? FPGAs are heavily used in telecom

and datacom infrastructure applications, so the combination of a custom NPU implementation with optimized memory (perhaps content-addressable memory) and a large pool of FPGAstyle logic would represent a highly programmable network platform for communications systems houses in the future.

ithin the next 10 years, we expect embedded system designers to work mostly from platform-based components. The path to this level of platform availability and interaction remains challenging. As the OMAP infrastructure shows, full-application platform development involves significant supporting programs and partnerships. Electronic design automation tools to develop the silicon are just starting to become available. For example, Cadence’s Virtual Component Co-Design environment specifically targets platformbased hardware-software co-design. Software development environments will have to undergo profound changes to manage the shift in design style. But then again, the compounding complexities of silicon processes, verification, and software development suggest that platform-based design is the only way to support the complex product and market requirements for next-generation embedded designs. ■

W

Grant Martin is a Fellow in the labs of Cadence Design Systems. Contact him at [email protected].

Frank Schirrmeister is a business director in the Systems and Functional Verification group of Cadence Design Systems. Contact him at franks@ cadence.com.

Suggest Documents