Video Messaging for ARM7-based Cellular Chipsets.
By Hantro
The market for video enabled mobile handsets is experiencing rapid growth as wireless operators deploy data networks and seek new applications to increase revenues per subscriber. The first handsets with embedded cameras were launched in 2002 and it is estimated that by 2005, 24% of all new handsets sold will be equipped with camera functionality, incorporating some level of video processing capability whether for messaging, streaming or two-way video communications.
This development has caused increasing demands for handset OEMs/ODMs, as well as silicon manufacturers, to design video capabilities into devices. The main question then becomes what would be the best approach to implement these new features?
The approaches to choose from are many, and the choice should be dictated by few key drivers, namely cost, required performance and available design time. An entry-level device can be implemented rapidly with software only, whereas high performance flagship product requires hardware acceleration in order to be able to provide highest quality video expected in this class of devices.
To provide further insight into designing an entry-level video terminal, we describe how a video messaging application can be implemented on a low cost mobile terminal platform using optimized software components. The solution represents the fastest time-to-market option for a low cost device. Since the device only hosts a rather low power processor such as ARM7, the performance of the applications is limited. It should, however, be noted that the same application would provide higher performance with faster processors, such as ARM9 or ARM11. Alternatively, the required performance can be generated using hardware acceleration, which will free the CPU for other tasks such as running advanced operating system and/or other applications.
2.5G HANDSET SYSTEM ARCHITECTURE
Current cellular handset designs are based on highly integrated silicon solutions. The number of active integrated circuit components is usually less than 10 (including memory chips). The core of a cellular phone chipset is a digital baseband (BB) and application chip. The BB chip runs all protocol and application level software. Most BB chips in use today have been implemented using a dual-core architecture: low level protocol software, such as forward error correction and channel equalization, runs in a digital signal processor (DSP) core, while higherlevel protocol software, as well as system control and application level software run on a micro-control unit (MCU) core.
A vast majority of both commercial and proprietary baseband chips use the MCU cores developed by ARM. The most popular core in BB chips used in high-volume handsets is the ARM7. The more powerful ARM9 core is currently used in higher-cost smartphone designs. The DSP cores used in BB chips, on the other hand, are usually chip vendor specific. Many chips feature on-chip, zero wait state SRAM memories that speed up program execution and reduce power dissipation.
Examples of popular ARM7-based chipsets are the SoftFone GSM/GPRS chipset from Analog Devices, and the MSM5100 CDMA chipset from Qualcomm. ARM7-based cellular chipsets are also available from Agere, Broadcom, Motorola, Philips, Skyworks and ST Microelectronics. Additional features, such as cameras, Bluetooth and FM radio reception are implemented using separate chips.
PERFORMANCE OF THE ARM® 7 CPU
The ARM7 core has proved to be an optimal solution for handset design, the main factors contributing to its success being:
- Small silicon area
- Low power consumption, and
- Good performance (0.9 MIPS/MHz)
The ARM7TDMI processor core is usually augmented with on-chip cache memories to increase the performance. This is especially important in mobile devices, where the off-chip memories are usually slow because of cost and power consumption limitations, as compared to desktop systems.
The ARM7® core can run at clock frequencies up to 70 MHz. Typically a lower clock frequency than that is used in handsets because of power reasons. Remembering that the CPU has to execute timing critical protocol software during voice and data calls, it is obvious that it cannot handle real-time multimedia communications applications at such low clock speeds. On the other hand, in between calls the most of the CPU capacity is free for applications that do not use the wireless communication link. Of such applications, imaging and video have become extremely popular.
VIDEO MESSAGING APPLICATION PERFORMANCE ON ARM® CPUS’
Video messaging application software on mobile phones consists of two functionally distinct parts: message creation and playback, and message transmission and reception. The latter is implemented according to the specifications of the 3GPP, and it makes use of the WAP application-level protocol for message delivery over a radio bearer, such as GPRS. Video message creation is carried out using a separate user-application that implements video capture and playback functionality. The main parts of such a camcorder application are:
- MPEG-4 Simple Profile/H.263 video codec
- Pre- and post processing (colour conversion and image scaling)
- GSM-AMR voice codec
- 3GP file format support
- Application engine (video and audio capture and play).
If a voice codec exists in the system, the camcorder application can make use of it. The other parts do not usually exist in 2.5G handset designs, and have to be implemented as part of the application. The overall software architecture of a camcorder application is shown in the figure below.
MPEG-4 encoding is the most critical part of the camcorder application. It sets the requirement for the CPU, or vice versa, the CPU performance sets a limit to the video quality in terms of image size and frame rate. Assuming that the voice codec runs on a DSP, the other parts of the camcorder application are less critical.
Typical image sizes used in mobile video are CIF (352x288, common image format), QCIF (176x144, quarter CIF) and SQCIF (128x96, Sub-QCIF). Performance requirements of the camcorder software components are shown below for SQCIF and QCIF image sizes. The performance figures have been obtained by simulating Hantro’s optimized software components on the ARM ADS1.2 simulator using the zero wait state memory model. The Foreman sequence was used for the purposes of this simulation.
Video Quality | Function | Clock frequency (MHz) | |
ARM7TDMI | ARM920T | ||
SQCIF, 10 fps | MPEG-4 Encode | 23 MHz v17 MHz | |
MPEG-4 Decode | 8 MHz | 6 MHz | |
YUV to RGB | 5 MHz | 3 MHz | |
Deblocking | 2 MHz | 2 MHz | |
QCIF, 15 fps | MPEG-4 Encode | 63 MHz | 47 MHz |
MPEG-4 Decode | 20 MHz | 16 MHz | |
YUV to RGB | 15 MHz | 8 MHz | |
Deblocking | 6 MHz | 5 MHz |
Based on these performance figures, we can conclude that SQCIF @ 10fps grade MPEG-4 video messaging is possible on current generation handsets that feature ARM7-based baseband processor chips. This is very important news to handset manufacturers: because of the wellknown delays in 3G cellular network deployments, the OEMs have no imminent reason to upgrade their current handsets silicon platforms to support new multimedia applications relying on high-speed data connections. By adding video messaging capability to an existing handset design, the OEMs can respond to customers’ needs rapidly and at a low cost.
Hantro has implemented a camcorder application for an OEM whose handset design is built around an ARM7-based baseband chip running at 39 MHz. Using SQCIF image size, the application achieved the encoding and decoding speeds of 6 fps and 10 fps, respectively. The decoding speed was actually limited by the speed of the display interface of the phone. The memory footprint of the application is 195 kB for program code, while the run-time data requirement is 50 kB during playback and 87 kB during video capture.
HANTRO’S MULTIMEDIA FRAMEWORK
Hantro’s multimedia framework consists of a set of optimized software and hardware modules that can be used to rapidly build a solution that meets a customer’s performance, cost and time-to-market needs. The software components in the framework are highly optimized, platform independent codecs and application engines that can be rapidly ported to a customer’s target environment (processor and operating system). Hantro has delivered solutions based on its multimedia framework to customers using ARM architecture-based processors running Symbian, Windows CE, PalmOS and eLinux operating systems, as well as various RTOS’s.
Hantro in brief
Hantro creates the leading edge technology that enables the mobile information society to leverage the power and value of wireless video.
Hantro provides its customers with video solutions for handheld devices. Hantro has both hardware and software based MPEG4 and H.263 standards based video codecs that have been delivered to customers and are proven solutions. Hantro’s product portfolio also includes video applications for capturing, playback, messaging, streaming and telephony. The company’s products play a key role in the development of battery operated video capable end products like cellular phones, still cameras, PDAs, camcorders, PC cameras and web pads.
|
On2 Technologies Inc. Hot IP
Related Articles
- Applications And Operations of Video Analytics
- VESA Video Compression on MIPI DSI-2 Enables Next-Generation Display Applications
- Software Infrastructure of an embedded Video Processor Core for Multimedia Solutions
- Why Low Complexity Video Coding is Answer to UHD TV Success
- Transitioning from DDR4 to DDR5 DIMM Buffer Chipsets
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
E-mail This Article | Printer-Friendly Page |