26-04-2011, 04:54 PM
[attachment=12882]
CHAPTER 1
INTRODUCTION
Today’s wireless mobile devices offer a wealth of applications, everything from Internet browsing to video playback and record to CD-quality audio playback. In addition, mobile phones are offering applications requiring multiple antennas, such as FM, GPS, Bluetooth® and WLAN. Designing a platform that can successfully incorporate all of these applications as well as the next generation of applications, such as HD video, high-fidelity audio and digital\ SLR-like imaging is a challenge.
To create the best possible user experience, it takes a whole new way of looking at the design of the device. Handsets are no longer just for making a phone call and perhaps receiving a text. A use case might look like this: You are in the middle of watching a movie streaming over WLAN when a call comes through. The best use case would be for the phone to automatically switch to the call using your Bluetooth headset, pausing the movie, and then when the caller hangs up automatically switching back to the movie and resume playing from where you left off.
Designing for these complex use cases requires breaking it down into the system components, such as Bluetooth, video encode/ decode, image processing, audio, etc. Each component can then be optimized as well as the interaction between components and the system. The OMAP™ 5 processor platform from TI has been designed with this philosophy to make customer development faster and easier by removing any roadblocks before the actual handset design starts.
The wireless market is huge and growing. Just five years ago, only 0.5 percent of the worldwide market owned wireless telephones or related appliances. Sales amounted to only 20 million units. Today, market penetration is about nine percent, with annual sales of more than 400 million units. Dataquest estimates that, in just three more years, 18 percent of the worldwide market will own wireless appliances.
As demand grows, so do consumer expectations. The wireless revolution is moving rapidly beyond voice to include such sophisticated applications as mobile e-commerce, real-time Internet, speech recognition, audio and full-motion video streaming. As a result, wireless Internet appliances require increasingly complex mobile communications and signal processing capabilities. And while consumers expect state-of-the-art functionality, they continue to demand longer battery life and smaller, sleeker products.
To provide these seemingly paradoxical characteristics—processing power for sophisticated applications with no reduction in battery life—wireless Internet appliance OEMs require the highly efficient, power-stingy processing delivered by the Open Multimedia Applications Platform™ (OMAP™) architecture from Texas Instruments.
OMAP hardware and software can decode data streams, such as MP3 audio and MPEG-4
video , in real time with just a fraction of the power required when using a best-in-class RISC processor
The advanced OMAP architecture provides a system solution for the wireless market. It seamlessly integrates a software infrastructure, an ARM™ RISC processor, a high-performance, ultra-low-power TI TMS320C55x™ generation digital signal processor (DSP) and shared memory architecture on the same piece of silicon. The OMAP software infrastructure includes support for advanced operating systems and applications through standard APIs. TI’s unique DSP/BIOS™ Bridge allows the developer to optimally partition tasks between the RISC and the DSP to maximize performance without sacrificing battery power.
Third-party developers, in turn, can anticipate the largest possible markets for their innovations because their software need not be OS specific. Integrating available third-party and OS native tools with TI's user-friendly Code Composer Studio™ integrated development environment (IDE) makes complete software development support available for the OMAP hardware and software architecture.
Available tool kits allow developers to work with an OMAP device as easily as if it were a RISC processor alone while gaining the power/performance benefits of a dual processor.
For OEMs and third-party developers, the fact that the tools eliminate the need to address the RISC and the DSP independently facilitates the creation of wireless multimedia applications and helps get them to market quickly.
In addition, the OMAP application environment is fully programmable. This programmability allows wireless device OEMs, independent developers, and carriers to provide downloadable software upgrades as standards change or bugs are found. Since there is no need to develop new ASIC hardware to implement changes, OMAP OEMs can respond to changing market conditions much more quickly than many of their competitors can. Because it is an open architecture with a standardized interface, the OMAP architecture encourages third-party developers to create new applications or add functionality. It also encourages reuse because the standardized interface allows OEMs to move software easily from one platform to another. Reusing existing software and adding innovations from outside developers help OEMs get to market quickly with differentiated features.
The fact that the OMAP architecture can be ported to any wireless device operating system (OS) and is compatible with applications written for most OSs, including Symbian’s EPOC™ and Microsoft Windows CE™, simplifies the development process for equipment makers seeking the broadest possible market. OEMs can maximize their investments by adapting in-house or third-party software to emerging operating systems.
CHAPTER 2
OMAP H/W ARCHITECTURE
2.1 What is a platform?
OMAP defines a platform as ”a packaged capability used in subsequent stages of the development to reduce development costs”.
Platforms have the following characteristics:
Between silicon and systems many platforms may be developed and used in subsequent stages of the development.
Platforms are valuable due to the notion of reuse (good for economy).
They include hardware, software, assemblies and tools.
The OMAP platform
OMAP products are combinations of hardware and software allowing mutimedia capabilities to be included in 2.5G and 3G wireless handsets and PDAs.
Critical design paramters are: Performance, Power, Cost and Time-to-Market.
First Approach: ”Opportunistic Reuse”.
No planned reuse, but try to reuse whenever possible.
Second Approach: ”Structured Approach”.
Systematic Reuse, SoC Platform.
OMAP: Hierarchy of Platforms
Figure 2.1 Hierarchy
OMAP uses platforms on different levels.
This is a precondition for reuse.
Examples for platforms
Transistor and ASIC libraries are the lowest hardware platforms.
Instruction Set Architecture and associated Assembly Language Tools are the lowest
level in Software.
These well-understood levels are used by other OMAP platforms.
2.2 OMAP Architecture
The OMAP architectute consisting of general purpose processor and DSP has been chosen because of the application area
Need for Performance.
Energy and Area Constraints.
Two Main Tasks: User Interface and Signal Processing.
Flexibility and Reuse.
manufacturing techniques; the choice of which will depend on the device being created and the market sector in which it has to operate.
Figure 2.2 OMAP Architectut
OMAP seamlessly integrates the following on the same piece of silicon:
Software infrastructure.
An ARM™ RISC processor.
A high-performance, ultra-low-power TI TMS320C55x™ generation digital signal processor (DSP).
Shared memory architecture using DSP/BIOS bridge.
Why use DSP ?
Most general-purpose microprocessors and operating systems can execute DSP algorithms successfully.
Microprocessor not suitable for application of mobile telephone and pocket PDA systems etc. because of power supply and space limit.
Specialized digital signal processor tend to provide a lower-cost solution, with better performance and lower latency.
2.3 OMAP DSP/BIOS Bridge
The DSP/BIOS Bridge is the key to OMAP architecture functionality and ease of use. It provides the application software developer a seamless, easy-to-use interface to the DSP. It allows the developer on the RISC to access and control the DSP runtime environment using a standardized application programming interface (API). From the developer’s perspective, using TI’s Code Composer Studio IDE makes the OMAP devices appear to behave and respond as though a single RISC processor alone were handling all functions. There is no need for the developer to program for the two processors independently or to work in the more difficult language environments sometimes associated with DSPs. A skilled RISC developer can quickly and easily adapt those skills to take advantage of the OMAP architecture’s superior power and performance characteristics.
Figure 2.3 DSP/BIOS Bridge
In a RISC-only system, the OS kernel schedules operations to run on the processor. Subsystems such as graphic interfaces and gaming programs rely on the RISC to schedule the available processing power and optimize these demanding software functions without choking the RISC processor completely. Adding a DSP processor, which is ideally suited for these processing-intensive functions, relieves the concern that the RISC processor will be overloaded. Allocating parallel functions to the two processors greatly reduces the possibility that an application will halt in mid-execution because the RISC has diverted processing power to another activity.
In the OMAP platform, the RISC OS kernel serves the same function as it does in a system using RISC alone, but the DSP/BIOS Bridge allows software developers to reroute the processing-intensive functions to the DSP, where they run asynchronously with no load on the RISC kernel scheduling. In some cases, the RISC processor exercises only a limited number of command and control functions, while the DSP provides the processing muscle needed for the application. A media file will run asynchronously on the DSP without the interrupts and latencies inherent when a RISC processor performs signal processing, resulting in a more robust, user-acceptable implementation.
CHAPTER 1
INTRODUCTION
Today’s wireless mobile devices offer a wealth of applications, everything from Internet browsing to video playback and record to CD-quality audio playback. In addition, mobile phones are offering applications requiring multiple antennas, such as FM, GPS, Bluetooth® and WLAN. Designing a platform that can successfully incorporate all of these applications as well as the next generation of applications, such as HD video, high-fidelity audio and digital\ SLR-like imaging is a challenge.
To create the best possible user experience, it takes a whole new way of looking at the design of the device. Handsets are no longer just for making a phone call and perhaps receiving a text. A use case might look like this: You are in the middle of watching a movie streaming over WLAN when a call comes through. The best use case would be for the phone to automatically switch to the call using your Bluetooth headset, pausing the movie, and then when the caller hangs up automatically switching back to the movie and resume playing from where you left off.
Designing for these complex use cases requires breaking it down into the system components, such as Bluetooth, video encode/ decode, image processing, audio, etc. Each component can then be optimized as well as the interaction between components and the system. The OMAP™ 5 processor platform from TI has been designed with this philosophy to make customer development faster and easier by removing any roadblocks before the actual handset design starts.
The wireless market is huge and growing. Just five years ago, only 0.5 percent of the worldwide market owned wireless telephones or related appliances. Sales amounted to only 20 million units. Today, market penetration is about nine percent, with annual sales of more than 400 million units. Dataquest estimates that, in just three more years, 18 percent of the worldwide market will own wireless appliances.
As demand grows, so do consumer expectations. The wireless revolution is moving rapidly beyond voice to include such sophisticated applications as mobile e-commerce, real-time Internet, speech recognition, audio and full-motion video streaming. As a result, wireless Internet appliances require increasingly complex mobile communications and signal processing capabilities. And while consumers expect state-of-the-art functionality, they continue to demand longer battery life and smaller, sleeker products.
To provide these seemingly paradoxical characteristics—processing power for sophisticated applications with no reduction in battery life—wireless Internet appliance OEMs require the highly efficient, power-stingy processing delivered by the Open Multimedia Applications Platform™ (OMAP™) architecture from Texas Instruments.
OMAP hardware and software can decode data streams, such as MP3 audio and MPEG-4
video , in real time with just a fraction of the power required when using a best-in-class RISC processor
The advanced OMAP architecture provides a system solution for the wireless market. It seamlessly integrates a software infrastructure, an ARM™ RISC processor, a high-performance, ultra-low-power TI TMS320C55x™ generation digital signal processor (DSP) and shared memory architecture on the same piece of silicon. The OMAP software infrastructure includes support for advanced operating systems and applications through standard APIs. TI’s unique DSP/BIOS™ Bridge allows the developer to optimally partition tasks between the RISC and the DSP to maximize performance without sacrificing battery power.
Third-party developers, in turn, can anticipate the largest possible markets for their innovations because their software need not be OS specific. Integrating available third-party and OS native tools with TI's user-friendly Code Composer Studio™ integrated development environment (IDE) makes complete software development support available for the OMAP hardware and software architecture.
Available tool kits allow developers to work with an OMAP device as easily as if it were a RISC processor alone while gaining the power/performance benefits of a dual processor.
For OEMs and third-party developers, the fact that the tools eliminate the need to address the RISC and the DSP independently facilitates the creation of wireless multimedia applications and helps get them to market quickly.
In addition, the OMAP application environment is fully programmable. This programmability allows wireless device OEMs, independent developers, and carriers to provide downloadable software upgrades as standards change or bugs are found. Since there is no need to develop new ASIC hardware to implement changes, OMAP OEMs can respond to changing market conditions much more quickly than many of their competitors can. Because it is an open architecture with a standardized interface, the OMAP architecture encourages third-party developers to create new applications or add functionality. It also encourages reuse because the standardized interface allows OEMs to move software easily from one platform to another. Reusing existing software and adding innovations from outside developers help OEMs get to market quickly with differentiated features.
The fact that the OMAP architecture can be ported to any wireless device operating system (OS) and is compatible with applications written for most OSs, including Symbian’s EPOC™ and Microsoft Windows CE™, simplifies the development process for equipment makers seeking the broadest possible market. OEMs can maximize their investments by adapting in-house or third-party software to emerging operating systems.
CHAPTER 2
OMAP H/W ARCHITECTURE
2.1 What is a platform?
OMAP defines a platform as ”a packaged capability used in subsequent stages of the development to reduce development costs”.
Platforms have the following characteristics:
Between silicon and systems many platforms may be developed and used in subsequent stages of the development.
Platforms are valuable due to the notion of reuse (good for economy).
They include hardware, software, assemblies and tools.
The OMAP platform
OMAP products are combinations of hardware and software allowing mutimedia capabilities to be included in 2.5G and 3G wireless handsets and PDAs.
Critical design paramters are: Performance, Power, Cost and Time-to-Market.
First Approach: ”Opportunistic Reuse”.
No planned reuse, but try to reuse whenever possible.
Second Approach: ”Structured Approach”.
Systematic Reuse, SoC Platform.
OMAP: Hierarchy of Platforms
Figure 2.1 Hierarchy
OMAP uses platforms on different levels.
This is a precondition for reuse.
Examples for platforms
Transistor and ASIC libraries are the lowest hardware platforms.
Instruction Set Architecture and associated Assembly Language Tools are the lowest
level in Software.
These well-understood levels are used by other OMAP platforms.
2.2 OMAP Architecture
The OMAP architectute consisting of general purpose processor and DSP has been chosen because of the application area
Need for Performance.
Energy and Area Constraints.
Two Main Tasks: User Interface and Signal Processing.
Flexibility and Reuse.
manufacturing techniques; the choice of which will depend on the device being created and the market sector in which it has to operate.
Figure 2.2 OMAP Architectut
OMAP seamlessly integrates the following on the same piece of silicon:
Software infrastructure.
An ARM™ RISC processor.
A high-performance, ultra-low-power TI TMS320C55x™ generation digital signal processor (DSP).
Shared memory architecture using DSP/BIOS bridge.
Why use DSP ?
Most general-purpose microprocessors and operating systems can execute DSP algorithms successfully.
Microprocessor not suitable for application of mobile telephone and pocket PDA systems etc. because of power supply and space limit.
Specialized digital signal processor tend to provide a lower-cost solution, with better performance and lower latency.
2.3 OMAP DSP/BIOS Bridge
The DSP/BIOS Bridge is the key to OMAP architecture functionality and ease of use. It provides the application software developer a seamless, easy-to-use interface to the DSP. It allows the developer on the RISC to access and control the DSP runtime environment using a standardized application programming interface (API). From the developer’s perspective, using TI’s Code Composer Studio IDE makes the OMAP devices appear to behave and respond as though a single RISC processor alone were handling all functions. There is no need for the developer to program for the two processors independently or to work in the more difficult language environments sometimes associated with DSPs. A skilled RISC developer can quickly and easily adapt those skills to take advantage of the OMAP architecture’s superior power and performance characteristics.
Figure 2.3 DSP/BIOS Bridge
In a RISC-only system, the OS kernel schedules operations to run on the processor. Subsystems such as graphic interfaces and gaming programs rely on the RISC to schedule the available processing power and optimize these demanding software functions without choking the RISC processor completely. Adding a DSP processor, which is ideally suited for these processing-intensive functions, relieves the concern that the RISC processor will be overloaded. Allocating parallel functions to the two processors greatly reduces the possibility that an application will halt in mid-execution because the RISC has diverted processing power to another activity.
In the OMAP platform, the RISC OS kernel serves the same function as it does in a system using RISC alone, but the DSP/BIOS Bridge allows software developers to reroute the processing-intensive functions to the DSP, where they run asynchronously with no load on the RISC kernel scheduling. In some cases, the RISC processor exercises only a limited number of command and control functions, while the DSP provides the processing muscle needed for the application. A media file will run asynchronously on the DSP without the interrupts and latencies inherent when a RISC processor performs signal processing, resulting in a more robust, user-acceptable implementation.