Updates: Samsung cuts LTE chip cost by half, ABI Research teardown reveals [Feb 7, 2012]
The Samsung Galaxy Nexus made a big impact on the market in December 2011, thanks to its sleek design, new Android OS (Ice Cream Sandwich) and NFC capability. The smartphone has another notable hidden feature that makes it more cost-competitive.
The Samsung Galaxy Nexus modem is constructed with the combination of a VIA Telecom CDMA/EVDO Rev.A integrated circuit and a Samsung LTE baseband integrated circuit, ABI Research said in its teardown note. This combination is now common for Samsung’s Verizon phones, but the Galaxy Nexus sports a new version of the LTE baseband chip. The new chip is estimated at nearly half the cost of the prior chip’s US$23 price tag.
This cost reduction is an important milestone in securing the rapid migration to LTE throughout the world, ABI Research indicated.
The application processor found inside the Galaxy Nexus is a TI OMAP4460, which runs at 1.2GHz, according to ABI Research. Other notables include an NFC antenna embedded in the device battery, and a CSR GPS single chip, a Broadcom Wi-Fi/BT/FM single chip and an Avago LTE PA and GPS frontend.
– Samsung Electronics Announces Fourth Quarter & FY 2011 Results [Samsung press release, Jan 27, 2012]
“Despite intensified competition amid the global economic slowdown, our Telecommunications businesses continued to post solid earnings with an enhanced line-up of high-end smartphones, resulting in higher average selling price (ASP). Moreover, improved profitability and earnings growth of our Set businesses, including smartphones and flat panel TVs led to our company’s strong earnings,” said Robert Yi, Senior Vice President and Head of Investor Relations.
Smartphone Sales Remain Main Driver
The Telecommunications businesses – including mobile communications and telecommunication systems – posted a record quarterly operating profit of 2.64 trillion won for the period. Fourth quarter revenue reached a record 17.82 trillion won compared with 11.75 trillion won for the same period of 2010.
The stellar performance has allowed Samsung to register full year 2011 operating profit of 8.27 trillion won, up 90 percent on-year. Total sales for fiscal year 2011 also hit an all-time yearly high of 55.53 trillion won, accounting for almost one-third of Samsung Electronics’ total revenue for the year.
Samsung’s flagship GALAXY S II smartphone and its full lineup of high-end mobile devices, such as the GALAXY Note and the GALAXY Nexus, and entry-level models drove up revenue for the year by almost 40 percent compared with the previous year.
All told, shipments of Samsung smartphones rose by approximately 30 percent in the fourth quarter, compared with the previous quarter.
For the global market outlook for this year, demand for entry-level smartphones and tablet PCs will increase significantly, while the growth momentum for feature phones is expected to stay static. Emerging markets and the spread of LTE (Long-Term Evolution) wireless telecommunications technology have also contributed to the growth of the smartphone market, which is expected to grow by more than 30 percent.
The Telecommunication System Business will further solidify its leadership in the wireless network market with the expansion of the LTE service in Korea and North America.
4Q FY2011 Earnings Conference Call [Samsung presentation, Jan 27, 2012]
End of updates
Samsung and Google introduce GALAXY Nexus [Samsung Mobile press release, Oct 19, 2011]
World’s First Smartphone to feature Android 4.0 Ice Cream Sandwich and a HD Super AMOLED display
Best-in-class hardware meets the most advanced software
GALAXY Nexus is the first smartphone to feature a 4.65’’ display with a market-leading resolution of 720p (1280×720), ensuring you can enjoy GALAXY Nexus’ immersive entertainment capabilities and fast web browsing in superior clarity.
Succeeding the original Contour Display of Nexus S, GALAXY Nexus comes with a rounded shape that fits perfectly within your palm or to your face for phone calling. Hyper-skin backing on the battery cover improves the ergonomic feel of the device and makes the phone slip-resistant. At just 8.94mm thick, with a minimal 4.29mm bezel, GALAXY Nexus provides superb portability alongside an expansive screen.
GALAXY Nexus also features an ultra-fast 1.2GHz dual core processor, providing superior power and speed, ensuring you can take full advantage of GALAXY Nexus’ enhanced multitasking capabilities with ease, or enjoy the large, vivid display to its full capacity with high-definition gaming or video streaming. LTE or HSPA＋ connectivity combined with a dual core processor delivers high-speed web browsing which ensures you always have the web at your fingertips, wherever you are.
GALAXY Nexus will be available in the U.S., Europe, and Asia beginning in Novemberand gradually rolled out to other global markets.
Network HSPA＋ 21Mbps/HSUPA 5.76Mbps 850/900/1900/1700/2100
＊LTE version will be available depending on the region.
Processor 1.2 GHz Dual Core Processor Display 4.65” 1280X720 HD Super AMOLED OS Android 4.0, Ice Cream Sandwich Camera Main(Rear) : 5 MP AF with LED Flash with zero shutter lag and fast shot2shot
Sub (Front) : 1.3MP for Video Call
Video Codec : MPEG4/H.263/H.264
Playback : 1080p@ 30fps
Recording : 1080p Full HD Video@ 30fps
Audio Codec : MP3/AAC/AAC＋/eAAC＋3.5mm Ear Jack Google™Mobile Services Android Market™, Gmail™, Google Earth™, YouTube™, Movie Studio
Google Maps™ 5.0 with 3D maps and turn-by-turn navigation
Syncing with Google Calendar™, Google＋ app
Connectivity Bluetooth® technology v 3.0 USB 2.0
Wi-Fi 802.11 a/b/g/n (2.4GHz/ 5GHz)
Sensor Accelerometer, Compass, Gyro, Light, Proximity, Barometer Memory 1GB(RAM) ＋ 16GB/ 32GB Internal memory Size 135.5 x 67.94 x 8.94mm, 135g Battery Standard battery, Li-on 1,750 mAh
TI confirms OMAP 4460 is in Nexus Galaxy [Oct 19, 2011]
We got word from TI that says it clearly. “Yes, the highly-anticipated Android 4.0 “Ice Cream Sandwich” release runs on the OMAP4460 processor.”
They went on to say that this is mainly due the fact they are better than the competition. They claim “the ability to provide hardware-integrated security, distinctive and advanced imaging features, enhanced memory and
more, all on a smart multicore architecture.”
TI’s vice president of OMAP platform business, Remi El-Ouazzane continues with something we will break into a separate story. He tells the word that OMAP 4460 is inside Nexus and that they are the first with Android 4.0 phone. It looks like they are the reference even for Ice Cream Sandwich tablets.
“What I may be the most excited by is not only the ability to converge to one Android release for both smartphones and tablets, but to be able to pack that level of performance across graphics or video on an HD screen and within the power envelope of a smartphone device.This is where our OMAP smart multicore architecture makes a huge difference,” he said.
Also, He goes after Nvidia with this comment: “At the end of the day, brute force (number of cores, for instance) does not rival sophistication.” TI is telling the world that their two core with great video and graphics with great power is just enough.
|ARM® Cortex™-A9 Clock Speed (two)||1 GHz||1.5 GHz||1.8 GHz|
|2D & 3D Graphics||Hardware accelerated
[POWERVR™ SGX540, greater than 2x the sustained performance compared to the previous SGX530 core]
[POWERVR™ SGX540, greater than 2x the sustained performance compared to the previous SGX530 core ]
Dedicated 2D and 3D graphic cores [POWERVR™ SGX544, more than two times the sustained performance compared to the previous SGX540 core performances, supports DirectX with maximum hardware acceleration]
|Video performance (2D)||1080p HD||1080p HD||1080p HD|
|Video Performance (3D)||720p stereoscopic 3D||1080p Stereoscopic 3D||1080p Stereoscopic 3D|
|Imaging Performance (per second)||20 MP main camera
5MP stereo (dual cameras)
|20MP main camera
12 MP stereo (dual cameras)
|20MP main camera
12 MP stereo (dual cameras)
|Availability||Currently sampling||Currently sampling||Samples in 4Q 2011|
|Display Support||WUXGA (1920 x 1200)||WUXGA (1920 x 1200)||QXGA (2048×1536), multiple screens|
Why the Galaxy Nexus uses OMAP instead of Exynos [Oct 18, 2011]
The rumors seemed strange from the start — a Samsung phone with a Texas Instruments processor? Last year’s Nexus S was a Samsung device, and it was Samsung through and through with a 1GHz Hummingbird system-on-a-chip (SoC). Now here we are looking at the new Googleflagship, the Galaxy Nexus, and it has a TI OMAP4460 on the inside. Why not Samsung’s own Exynos part?
There area few factors at work here, but the most important one is related to how the Nexus program works. Back when Google announced the Motorola Mobility buy, the company finally revealed a bit about how it operates the Nexus program. This was done in an effort to show that Motorola won’t be getting preferential treatment.
According to Google’s Andy Rubin, each year Google selects a device maker that it wants to work closely with on the next Nexus phone. But it’s not just the OEM that is involved — Google decides on components in the phone individually. Unlike other devices, Google gets it way with the Nexus.
So the team that will eventually “huddle together in one building” will be made up of the OEM, and several component makers that supply things like the SoC and radios. Then 9-12 months later, a little Nexus is born. Last year, Google went with Samsungfor the device itself, and the SoC. This year, Google has decided to put Texas Instruments on the processor team.
So now the OMAP4460 is getting quite a lot of scrutiny, even though it isn’t exactly a new chip. This dual-core SoC is clocked at 1.2GHz, and uses ARM Cortex-A9 architecture, just like the Exynos. That’s not a problem, but the older GPU, the PowerVR SGX540 is. We were hoping for a step up in the graphics department.
[Samsung’s own Cortex A9 based SoC, Exynos 4210 [Sept 22, 2011] in 1GHz and 1.2GHz version is currently sampling.]
Why did Google choose the OMAP for its new Nexus? Well, it might not live up to the high graphical standards set out by the iPhone, but it is a solid chip in its own right. The OMAP4 platform makes use of an additional hardware accelerator called IVA 3 [IVA-HD as called in the Technical Reference below] that makes encoding and decoding HD video a snap. The Galaxy Nexus has an HD screen, so this hardware focus on video is a big plus.
Google engineers were likely also drawn to the OMAP for its use of a dual-channel memory controller. Android’s multitasking system means that data is constantly being moved into, and out of, active memory. This is definitely a strength of TI’s OMAP parts.
Google will be developing the new version of Android on OMAP for the next year, so be ready for more devices based on this one. Much like the Nexus One started the Snapdragon revolution two years ago, this could be TI’s time to shine. If that OMAP4460 starts looking old and tired to OEMs in the coming year, there is always the upcoming OMAP4470 (which is armed with the much-newer and faster SGX544 GPU) to maintain compatibility and increase performance, too.
One official benchmark (GLBenchmark 2.1) to show the GPU performance differences:
OMAP4460 Multimedia Device Silicon Revision 1.x – Technical Reference Manual [PRELIMINARY, February 2011–Revised October 2011, 5620 pages]
- NOTE: Missing functionality in OMAP4430 Multimedia Device Silicon Revision 2.x – Technical Reference Manual [July 2010–Revised October 2011, 5564 pages]
The OMAP4460 high-performance multimedia application device is based on enhanced OMAP™ architecture and uses 45-nm technology.
• The architecture is designed to provide best-in-class video, image, and graphics processing for 2.5/3G wireless terminals, high-performance personal digital assistants (PDAs). For that purpose, the device
supports the following functions:
– Streaming video up to full high definition (HD) (1920 × 1080 p, 30 fps)
– 2-dimensional (2D)/3-dimensional (3D) mobile gaming
– Video conferencing
– High-resolution still image (up to 16 Mp)
• The device supports high-level operating systems (OSs) such as:
– Palm OS™
– Symbian OS™
– Windows™ CE, WinMobile™
• The device is composed of the following subsystems:
– Cortex™-A9 microprocessor unit (MPU) subsystem, including two ARM® Cortex-A9 cores
– Digital signal processor (DSP) subsystem
– Image and video accelerator high-definition (IVA-HD [IVA 3 as called in marketing materials]) subsystem
– Cortex™-M3 MPU subsystem, including two ARM Cortex-M3 microprocessors
– Display subsystem
– Audio back-end (ABE) subsystem
– Imaging subsystem (ISS), consisting of image signal processor (ISP) and still image coprocessor (SIMCOP) block
– 2D/3D graphic accelerator (SGX) subsystem
– Emulation (EMU) subsystem
The purpose of the MA is to improve the missed latency of the L2 cache between the ARM Cortex-A9 processor and external memory. One of the PL310 master ports is connected to the MA and is used for all accesses to SCRAM. The PL310 address filtering mechanism is used to split incoming addresses between the MA connected to one of the PL310 master ports and the local interconnect connected to the other PL310 master port.
Cache Management Unit
The CMU provides the ability to perform maintenance operations on Cortex-A9 MPU caches by physical address range. This reduces the execution time required by the Cortex-A9 CPUs to perform cache maintenance operations, while improving the overall throughput of maintenance operations. This frees the CPUs for other useful work. The registers inside the CMU are configured using the 32-bit interconnect configuration port from the local interconnect. The CMU operates at half the clock speed of the CPU core.
EMIF Controller [EMI Module]
The EMIF [External Memory InterFace] module provides connectivity between the device and the LPDDR2-type memories and manages data bus read/write accesses between external memories, the microprocessor unit (MPU), and the direct memory access (DMA) controller.
The EMIF is an L3 bus peripheral that provides an interface to the LPDDR2 memories.
The diagram below shows the interconnection between the EMIF module and the other modules.
Digital locked loops (DLLs) are used to delay the input DQS signals during reads so that these strobe signals can be used to latch incoming data on the DQ pins, as required by the LPDDR2 standard.
Physical layers (PHYs) are hard macros that convert single-data rate (SDR) signals to DDR signals.
The EMIF supports three local interfaces: one connects to the system interconnect, one to a low-latency master, and one comes from the MPU half of the EMIF-to-MPU connection. These interfaces are used to request all external memory device accesses, to access the EMIF registers, and to transfer all data to and from the EMIF controller. … A third interface arranges the connection between the EMIF and the MPU. It is separated to the MPU half of the EMIF-to-MPU L3 Interface and the EMIF half of the EMIF-to-MPU L3 Interface.
• The device includes state-of-art power-management techniques required for high-performance mobile products.
• Comprehensive power management is integrated into the device.
• The device also integrates:
– On-chip memory
– External memory interfaces
– Memory management
– Level 3 (L3) and level 4 (L4) interconnects
– System and connecting peripherals
Cortex-A9 MPU Subsystem Description
The Cortex-A9 MPU subsystem [is based on the symmetric multiprocessor (SMP) architecture and] integrates the following submodules:
• ARM Cortex-A9 MPCore
– Two ARM Cortex-A9 central processing units (CPUs)
– ARM Version 7 ISA™: Standard ARM instruction set plus Thumb®-2, Jazelle® RCT and Jazelle DBX Java™ accelerators
– Neon™ SIMD coprocessor and VFPv3 per CPU
– Interrupt controller (Cortex-A9 MPU INTC) with up to 128 interrupt requests
– One general-purpose timer and one watchdog timer per CPU
– Debug and trace features
– 32-KB instruction and 32-KB data level 1 (L1) caches per CPU
• Shared 1-MB level 2 (L2) cache
• 48 KB bootable ROM
• Local power, reset, and clock management (PRCM) module
• Emulation features
• Digital phase-locked loop (DPLL)
ABE Subsystem Description
The ABE subsystem handles audio processing for the application. It manages the audio and voice streams between the Cortex-A9 MPU subsystem and/or DSP, and the physical interfaces.
The ABE subsystem allows:
• Buffering of audio samples
• Mixing audio with voice downstream and/or microphone upstream (sidetone)
• Postprocessing of equalization, 3D effects, bass-boost
The ABE subsystem consists of:
• Audio engine (AE) subsystem, which performs real-time signal processing such as:
– Muxing and mixing voice and data streams
– Postprocessing operations such as sampling rate conversion, volume control, 3D effects
– Execution of whole data transfers in the ABE subsystem using audio traffic controller (ATC)
The AE subsystem includes an AE and has the following on-chip memories available: 64-KB data memory (DMEM); 6-KB coefficient memory (CMEM); and 18-KB sample memory (SMEM).
The ATC manages the data movement in the ABE subsystem and is in charge of interrupt generation to the DSP and Cortex-A9 MPU subsystems.
• Four general-purpose timers (GPTIMERs) and one watchdog timer (WDTIMER)
• Peripheral interfaces:
– Three multichannel buffered serial ports (McBSPs) for inter-IC sound ( I2S™) external connectivity
– One multichannel audio serial port (McASP) supporting Sony/Philips digital interconnect format (S/PDIF) output
– One MIPI SLIMbus interface to support new generations of MIPI-compliant components
– One digital microphone (DMIC) for three stereo digital microphones support
– One multichannel pulse-density modulation (McPDM) interface, which ensures communication with the TWL6040 audio companion chip
• Internal interfaces for connection with the DSP and Cortex-A9 MPU subsystems and other modules in the device
• Dedicated power domain (ABE power domain)
DSP Subsystem Description
This information is not available in the public domain.
IVA-HD [IVA 3 as called in marketing materials] Subsystem Description
The IVA-HD subsystem is a set of video encoder/decoder hardware accelerators. It supports up to 1080p × 30 fps, slow-motion camcorder, triple play (HD and SD capture and JPEG capture), real-time transcoding of up to 720p, and video conferencing up to 720p.
The IVA-HD subsystem is composed of:
• Improved motion estimation acceleration engine (iME3), which is used in encoding processing
• Improved loop filter acceleration engine (iLF3), which performs deblocking filtering
• Improved sequencer (iCONT1) based on the ARM968E-S™ microcontroller. It includes memory and INTC and is used as a primary sequencer.
• Intraprediction estimation engine (iPE3). It is used in encoding processing.
• Calculation engine (CALC3), which performs transform and quantization calculations
• Motion compensation engine (MC3), which creates an interprediction macroblock with given motion vectors and modes from the reference data
• Entropy coder/decoder (ECD3), which uses Huffman and arithmetic codes during the process of encoding and decoding the stream
• Video DMA processor (iCONT2), which is also based on the ARM968E-S microcontroller and can be used as secondary sequencer
• Video DMA engine (vDMA), which is a DMA engine for data transmission between external memories and shared L2 memory
• Synchronization box (SyncBox) embedded in each hardware accelerator and in both iCONTs
• Mailbox for communication between IVA-HD and external to it processors (DSP, Cortex-A9, and Cortex-M3)
• Shared L2 interface and memory
• Video local interconnect for connection between the submodules of the IVA-HD, and between the IVA-HD and DSP subsystems
• IVA-HD system control module (SYSCTRL), which controls the clocks in the subsystem and PRCM handshaking
The IVA-HD subsystem can process three data formats for internal data: picture or slice, macroblock header, and residual data.
The IVA-HD supports [the following codec standards natively; that is, all functions of standards are accelerated (without any intervention of the digital signal processor [DSP])] the following formats:
• MPEG-1/-2/-4 such as MPEG-2 MP, ML, and MPEG-4 as SP/ASP
• Divx 5.02 and above
• Sorenson Spark [V0 and V1] (decode)
• H.263 P0 (encode and decode) and P3 (decode)
• H.264 Annex G (scalable baseline profile up to 720p)
• H.264 BP/MP/HP
• [H.264: Fast Profile/RCDO Encode and Decode]
• H.264 Annex H (partial) [up to 720p30]
• Stereoscopic video
• JPEG [(also MJPEG)] (encode/decode)
• VC-1 [WMV9/RTV] SP/MP/AP
• RealVideo® 8/9/10 (decode only)
• On2® VP6.2/VP7 (decode only)
[IVA-HD 1.0 will use eXpressDSP Digital Media (xDM) standard as the principle software interface. The xDM standard defines application programming interfaces (APIs) through which an application invokes a
particular class of codec, such as video decode or audio encode.
xDM developers kit, technical documentation and full compliant codecs can be downloaded from http://focus.ti.com/docs/toolsw/folders/print/tmdxdaisxdm.html.
Software released on IVA-HD 1.0 will be xDM-compliant and will be available during 2010.]
Display Subsystem Description
The display subsystem provides the control signals required to interface the OMAP system memory frame buffer (SDRAM) directly to the displays. [The display subsystem (DSS) provides the logic to display a video frame from the memory frame buffer on a liquid-crystal display (LCD) panel or a TV set.] It supports hardware cursor, independent gamma curve on all interfaces, multiple-buffer, and programmable color phase rotation. The display subsystem allows low-power display refresh and arbitration between normal and low-priority pipelines.
The display subsystem consists of the following sections:
• Display controller: It can read and display the encoded pixel data stored in memory and write the output of one of the overlays or one of the pipelines into the system memory. It supports the following components:
– Three video pipelines, one graphic pipeline, and one write-back pipeline. The graphic pipeline supports pixel formats such as: ARGB16-4444, RGB16-565, ARGB16-1555, ARGB32-8888, RGBA32-8888, RGB24-888, and BITMAP (1, 2, 4, or 8 bits per pixel). It allows selection of the
– Write-back pipeline: it uses poly-phase filtering for independent horizontal and vertical resampling (upsampling and downsampling). It allows programmable color space conversion of RGB24 into YUV4:2:2-UYVY, YUV4:2:2-YUV2, or YUV4:2:0-NV12, and selection of color-depth reduction from RGB24 to RGB16.
– Two LCD outputs, each one with dedicated overlay manager, for support of passive matrix color and monochrome displays (up to 8-bit interface) and active matrix color displays (up to 24-bit interface). Secondary LCD output is available through parallel CMOS interface for MIPI®-DPI 1.0
– One TV output with dedicated overlay manager
– Own direct memory access (DMA) engine
• Remote frame buffer interface (RFBI) module.
– Support for MIPI-DBI protocol
– 8-/9-/16-bit parallel interface
– Programmable pixel modes and output formats
• Two MIPI display serial interfaces (DSIs) with the following main features:
– Support for MIPI-DSI (four data-lane complex inputs/outputs (I/Os) for DSI1 and two data-lane complex I/Os for DSI2)
– Support for video mode and command mode
– Data interleaving support for synchronous and asynchronous streams
– Bidirectional data link support
• High-definition multimedia interface (HDMI) encoder with the following main features:
– HDMI 1.3, HDCP 1.2, and DVI 1.0 compliant
— Including support for the 3D Stereoscopic frame-packing formats of HDMI v1.4 standard (720p, 50Hz, 720p, 60Hz and 1080p, 24Hz)
– Deep-color mode support (10-bit for up to 1080p and up to 12-bit for 1080i/720p)
– Support for uncompressed multichannel audio
– Integrated high-bandwidth digital content protection (HDCP) encryption engine for transmitting protected audio and video content
– Integrated transition minimized differential signaling (TMDS) and TERC4 encoders for data island support
• NTSC/PAL video encoder with the following main features:
– Output to on-chip video digital-to-analog converter (VDAC) providing composite analog output signal: NTSC-J, M; PAL-B, D, G, H, I; PAL-M
– Support for square pixel sampling
– Programmable horizontal synchronization, vertical timing, and waveforms
NOTE: The NTSC/PAL video encoder and VDAC function are not supported.
Face Detect Module Description
The face detect module is a stand-alone module that performs face detection and tracking on a picture stored in the SDRAM memory. It communicates with the Cortex-A9 MPU, DSP, and Cortex-M3 MPU
Face detect is typically used on:
• Video encoding
• Face-based priority auto-focusing
• Red-eye removal
The face detect module comprises:
• Face detection core with embedded DMA engine for data memory access
• RAM and ROM memories
• L3 and L4 port interfaces
Cortex-M3 MPU Subsystem Description
[The dual Cortex™-M3 microprocessor (MPU) subsystem controls the imaging subsystem (ISS) and manages some controls of the video and display subsystem. It contains two ARM® Cortex-M3 processors (CPUs) that share a common level 1 (L1) cache (shared cache). One of the CPUs is dedicated to sequencing still image coprocessor (SIMCOP) accelerators, and the other CPU is dedicated to the ISS and display subsystem control. A single image real-time operating system (RTOS) runs on both cores, thereby minimizing the code size. The integrated interrupt handling of the dual Cortex-M3 MPU allows efficient control of the ISS.]
The Cortex-M3 MPU subsystem includes the following components:
• Two Cortex-M3 CPUs: One for SIMCOP control, and the other for RTOS, ISP, and display subsystem control
• ARMv7-M and Thumb-2 instruction set architecture
• Dedicated INTC with up to 64 physical interrupt events
• Two-level memory subsystem hierarchy
— 32-KB shared cache memory
– L2 ROM + RAM
— 64-KB RAM
— 16-KB bootable ROM
• Cortex-M3 system bus directly connected to the ISS interconnect
• MMU for address translation
• Integrated power management
• Emulation feature embedded in the Cortex-M3
[The imaging subsystem (ISS) deals with the processing of the pixel data coming from an external image sensor, data from memory (image format encoding and decoding can be done to and from memory), or data from SL2 in IVA-HD for hardware encoding. With its subparts, such as interfaces and interconnects, image signal processor (ISP), and still image coprocessor (SIMCOP), the ISS is a key component for the following multimedia applications: camera viewfinder, video record, and still image capture.]
The ISS processes data coming from the image sensor, memory, and IVA-HD subsystem. The ISS is responsible for multimedia applications such as: camera viewfinder; video record with up to 1080 p at 30 fps with digital zoom and still image processing, such as image capture up to 16 Mp with digital zoom and rotation. The ISS supports a pixel throughput of up to 200 Mp/s. It assures good performance with sensors up to 16 Mp and more (higher resolution can be achieved through multiple passes). The ISS can implement third-party algorithms for further flexibility when working with image sensors.
The ISS consists of:
• The ISP, which deals with on-the-fly or memory-to-memory data processing. It allows data collection for autoexposure, autowhite balance, autofocus, resizing, and histogram generation.
The ISP consists of:
– Image pipe interface (IPIPEIF) for synchronization signals (HD, VD) for the ISIF, IPIPE, RSZ, and hardware 3A (H3A) modules, and data transfer from video port, SDRAM, ISIF. Various pixel data manipulation functions.
– Image pipe (IPIPE) front-end and back-end modules for raw data processing and RGB and YUV data processing, respectively. They support:
— Sensor data linearization for dynamic range extension
— Programmable 2D lens shading compensation correction
— Black-level compensation
— Gamma correction
— RGB color correction
— RGB to YUV4:2:2 color conversion
— 3D look up table (LUT) for color correction
— 2D edge enhancement
— False chroma suppression
– H3A for autowhite balance, autoexposure, and autofocus
– Pattern generator (PG) for internal data generation for test purposes. It provides the ability to test some of the ISP submodules without the use of an external image sensor.
– Two independent resizers, which allow YUV4:2:2 to YUV4:2:0 planar Chroma filtering and downsampling. The resizers support input and output flows with up to 200 Mp/s, and memory-to-memory rescaling in the range ×1/4096 scale down, and ×20 scale up.– Image sensor interface (ISIF) can process the incoming data and supports the following main functions:
— Sensor data linearization
— Supports VGA read out mode
— Color space conversion
— Digital clamp with horizontal/vertical offset drift compensation
— Vertical line defect correction
— Programmable 2D-matrix lens shading correction
— 10-to-8 bits A-Law compression table inside
– Buffer logic (BL), which processes and manages the requests to the module and memory subsystem
• Peripheral serial interfaces for connection with sensors and memories:
– Two PHYs, CSIPHY1 and CSIPHY2, for physical connection to external sensors
– Peripheral serial interfaces CSI2-A and CSI2-B/CCP2 for image data transfer from sensors to memory or ISP
• Peripheral 16-bit parallel interface, BT656 and SYNC mode
[Parallel interface (CPI)
• 16 bits wide
• up to 148.5 MPix/s
• BT656 and SYNC mode (HS, VS, FIELD, WEN)
The camera subsystem can manage a parallel interface and [up to] two serial image sensors. Depending on the configuration of the shared pins, two of the interfaces can be active at the same time. However, only one data flow can use the ISP. Moreover, if the parallel interface is used data from it goes to ISP and the other used interface must send it to memory.]
• SIMCOP module for memory-to-memory operation; JPEG encode/decode hardware acceleration; high-ISO filtering; block-based rotation; warping and fusion; and general-purpose imaging acceleration.
The SIMCOP includes the following main submodules:
– Two imaging extension (iMX) modules – programmable image and video processing engines
– Noise filter 2 (NSF2) – for advanced noise filtering and edge-enhancement
– Variable-length coder/decoder for JPEG (VLCDJ) module
– Discrete cosine transform (DCT) module
– Lens distortion correction (LDC) module
– Rotation accelerator (ROT) engine
– Hardware sequencer, which offloads sequencing tasks from the MPU
– Shared buffers/memories
– DMA controller
• Timing control module for CAM global reset control, CAM flash strobe, and CAM shutter
• System interfaces and interconnects comprising:
– Two configuration interfaces
– One 128-bit master data interface
– Internal ISS interconnects for image data and configuration
– On-chip RAM interface
– Circular buffer (CBUFF) and burst-translation engine (BTE) for efficient communication with external memory (SDRAM/TILER support)
2D/3D Graphics Accelerator [SGX Subsystem] Description
The 2D/3D graphics accelerator subsystem is based on POWERVR® SGX540 core from Imagination Technologies. It supports phone/PDA and handheld gaming applications. [The POWERVR SGX540 v1.2.0 architecture is scalable and can target all market segments from mainstream mobile devices to high-end desktop graphics.] The SGX can process different data types simultaneously, such as: pixel data, vertex data, video data, and general-purpose data processing. [Targeted applications include feature phones, PDAs, and handheld gaming applications.]
The SGX subsystem has the following features:
• Universal scalable shader engine ( USSE™), multithreaded engine incorporating pixel and vertex shader functionality to reduce die area
• Advanced shader feature set in excess of Microsoft VS3.0, PS3.0, and OGL2.0
• Industry-standard API supports Direct3D™ Mobile, OGL-ES 1.1 and 2.0, OpenVG™ 1.1, and OpenMAX™
• Fine-grained task switching, load balancing, and power management
• Programmable high-quality image antialiasing
• Advanced geometry DMA driven operation for minimum CPU interaction
• Fully virtualized memory addressing for OS operation in a unified memory architecture
• Advanced and standard 2D operations, such as vector graphics, BLTs, ROPs, etc.
• Programmable video encode and decode support for H.264, H.263, MPEG-4 (SP), WMV9, and JPEG
On-Chip Debug Support [EMU Subsystem] Description
[Debugging a system containing an embedded processor involves an environment that connects high-level debugging software, executing on a host computer, to a low-level debug interface supported by the target
device. In between these levels is a debug and trace controller (DTC) that facilitates communication between the host debugger and the debug support logic on the target chip.
A combination of hardware and software that connects the host debugger to the target system, the DTC uses one or more hardware interfaces and/or protocols to convert actions dictated by the debugger user to
JTAG® commands and scans that execute the core hardware.
The debug software and hardware components let the user control multiple central processing unit (CPU) cores embedded in the device in a global or local manner. This environment provides:
• Synchronized global starting and stopping of multiple processors
• Starting and stopping of an individual processor
• Each processor can generate triggers that can be used to alter the execution flow of other processors.
System topics include but are not limited to:
• System clocking and power-down issues
• Interconnection of multiple devices
• Trigger channels
For easy integration into applications, a set of libraries (APIs) for debug-IP programming and a software message library are being provided. CToolsLib is a collection of embedded target APIs/library to enable
easy programmatic access to the chip tools (CTools), which are system-level debug facilities included in the debug subsystem capabilities of TI devices. More information about the APIs, download files, and
other useful links for available libraries can be found on the CToolsLib Wiki site: http://processors.wiki.ti.com/index.php/CToolsLib]
The on-chip debug support has the following features:
• Multiprocessor debugging lets users control multiple CPU cores embedded in the device, such as:
– Global starting and stopping of individual or multiple processors
– Each processor can generate triggers that can be used to alter the execution flow of other processors
– System clocking and power down
– Interconnection of multiple devices
– Channel triggering
• Target debugging, using IEEE1149.1 (JTAG®), or IEEE1149.7 (complementary superset of JTAG) port
• Reduction of power consumption in normal operating mode
• Real-time software trace allows the OMAP software masters to transmit trace data from OS processes or tasks on 256 different channels.
The debug subsystem includes:
• IEEE1149.7 adapter
• Generic TAP for emulation and test control ( ICEPick-D™)
• Debug access port (DAP)
• Processor trace subsystem
• System trace subsystem
• EMU configuration interconnect
• Cross-triggering unit (XTRIGGER)
• Debug resource manager (DRM)
• Controls the wake-up and power-down of the emulation power domain
CORE instrumentation interconnect:
• Initiator ports:
– L3 interconnect (for software instrumentation and performance probes)
– IVA-HD instrumentation (HWA profiling)
– CM2 instrumentation
• Target port:
– EMU instrumentation interconnect
OCP watch-point (OCP-WP):
• Monitors L3 interconnect transaction when target transaction attributes match the user-defined attributes or trigger on external debug event
• Only one instance, shared among the following L3 targets:
Power management events profiler (PM instrumentation)
Clock management events profiler (CM instrumentation)
Statistics collector (performance probes)
Power, Reset, and Clock Management [PRCM module]Description
The PRCM module allows efficient control of clocks and power according to the required performance, and reduction of power consumption.
[Power management (efficient use of the limited battery resources on a mobile device) is one of the most important design aspects of any mobile system. It imposes strong control over limited available power resources to ensure they function for the longest possible length of time.
The device power-management architecture ensures maximum performance and operation time for user satisfaction (audio/video support) while offering versatile power-management techniques for maximum design flexibility, depending on application requirements.
This introduction contains the following information:
• Power-management architecture building blocks for the device
• State-of-the-art power-management techniques supported by the power-management architecture of the device
To provide a versatile architecture supporting multiple power-management techniques, the power-management framework is built with three levels of resource management: clock, power, and voltage management.
These management levels are enforced by defining the managed entities or building blocks of the power-management architecture, called the clock, power, and voltage domains.
A domain is a group of modules or subsections of the device that share a common entity (for example, common clock source, common voltage source, or a common power switch). The group forming the domain is managed by a policy manager. For example, a clock for a clock domain is managed by a dedicated clock manager within the power, reset, and clock management (PRCM) module. The clock manager takes into consideration the joint clocking constraints of all the modules belonging to that clock domain (and, hence, receiving that clock).
NOTE: In the following sections, the term module is used to represent the device IPs (that is, modules or subsystems), other than the PRCM module, that receive clock, reset, or power signals from the PRCM module.
The PRCM module manages the gating (that is, switching off) and enabling of the clocks to the device modules. The clocks are managed based on the requirement constraints of the associated modules. The following sections identify the module clock characteristics, management policy, clock domains, and clock domain management.
The PRCM module manages the switching on and off of the power supply to the device modules. The power to the modules can be switched off when they are not in use to minimize device power consumption. Independent power control of sections of the device allow the PRCM module to turn on and off specific sections of the device without affecting the others.
The PRCM module controls the voltage scaling (that is, switching the voltage in discrete steps or in a continuum within a range of possible values) of the power sources of the device. This allows control of the
device power consumption according to the performance criteria defined. Higher performance is ensured with higher voltage and clock frequencies (and hence higher power consumption), while lower performance can be supported with lowered power consumption by reducing or completely gating the power supply to specific areas of the device and gating the associated clocks.
The PRCM module is divided into:
• Power and reset management (PRM), based on the SmartReflex™ framework with the following features:
– Dynamic clock gating
– Dynamic voltage and frequency scaling (DVFS)
– Dynamic power switching (DPS)
– Static leakage management (SLM)
– Adaptive body bias (ABB)
– Retention-till-access (RTA) for memories
• Clock management 1 (CM1) for clock generation, distribution, and management for the Cortex-A9 MPU, ABE, and CORE always-on power domains. The clock management allows reduction of dynamic
• Clock management 2 (CM2) for clock generation, distribution, and management for other modules
System and Connection Peripherals
The OMAP device supports a comprehensive set of peripherals to provide flexible and high-speed (HS) interfacing and on-chip programming resources.
System Peripherals [see on the above diagram]
• Seven general-purpose timers (GPTIMER)
• One watchdog timer (WDTIMER)
• One 32-kHz synchronization timer (32KTIMER)
• System control module, which contains registers for the following functions:
– Static device configuration
– Debug and observability
– Pad configuration
– I/O configuration
– eFuse logic
– Analog function control
– System boot decoding logic
• System mailbox with eight mailbox message queues
[Communication between the on-chip processors – Cortex-A9 MPU, DSP and Cortex-M3 MPU – of the device uses a queued mailbox-interrupt mechanism. The queued mailbox-interrupt mechanism allows the software to establish a communication channel between two processors through a set of registers and associated interrupt signals by sending and receiving messages (mailboxes). ]
• One SPINLOCK module [provides hardware assistance for synchronizing the processes running on multiple processors in the device] with 32 hardware semaphores, which can service tasks between the Cortex-A9 MPU, DSP, and Cortex-M3 MPU subsystems
• One chip-to-chip (C2C) interface, which [is a serial, low-latency, peer-to-peer communication protocol that enables the extension of an internal protocol bus to one physical device over a printed circuit board (PCB). It] services the communication between the OMAP device and external devices
… [see later]
On-Chip Memory Description
The on-chip memory is divided into L3 OCM RAM, SAR ROM, SAR RAM, and memories in the subsystems (Cortex-A9, Cortex-M3, ABE, and IVA-HD).
• The L3 OCM RAM consists of 56KB of on-chip SRAM.
• The save-and-restore (SAR) ROM [see on the above diagram] consists of 4KB and contains a linked list of descriptors used by the system DMA (sDMA).
• The SAR RAM [see on the above diagram] consists of 8KB divided into four blocks. It is used as context-saving memory when the device goes into off mode.
Memory Management Description
The memory management is performed from:
• sDMA controller with up to 127 requests, 32 prioritizable logical channels, and 256 × 64-bit FIFO
[The system direct memory access (SDMA) module, also called DMA4, performs high-performance data transfers between memories and peripheral devices without microprocessor unit (MPU) or digital signal
processor (DSP) support during transfer. A DMA transfer is programmed through a logical DMA channel, which allows the transfer to be optimally tailored to the requirements of the application. ]
• Dynamic memory management (DMM) module, which performs global address translation, address rotation (tiling), and access interleaving
[The dynamic memory manager (DMM) module is typically located immediately in front of the synchronous dynamic random access memory (SDRAM) controller (SDRC), as shown in the below diagram.
In a broad sense, the DMM manages various aspects of memory accesses such as:
– Initiator-indexed priority generation
– Multizone SDRAM interleaving configuration
– Block object transfer optimization – tiling
– Centralized low-latency page translation – MMU-like feature
The dynamic qualifier for memory management highlights the software configurability, and hence the runtime nature, of the four aspects of memory management handled by the DMM.]
External Memory Interface Description
There are two main interfaces for connection to external memories: general-purpose memory controller (GPMC) and dual-channel SDRAM controller (SDRC).
The GPMC [an unified memory controller dedicated to interfacing external memory devices] supports:
• Asynchronous SRAM memories
• Asynchronous/synchronous [, and page mode (available only in nonmuxed mode) burst] NOR flash memories
• NAND flash memories
• Pseudo-SRAM devices
The SDRC/EMIF [provides connectivity between the device and LPDDR2-type memory and] allows:
• Connection between the device and LPDDR2-type memory. It supports double-data rate (DDR) and single-data rate (SDR) protocols. The EMIF is the interface between LPDDR2 SDRAM and the Cortex-A9 MPU subsystem, ISS, IVA-HD subsystem, SGX, and DMA controllers.
• PHY is the DDR physical interface, which implements data-rate conversion in compliance with LPDDR2 JEDEC requirements.
System and Connection Peripherals
The OMAP device supports a comprehensive set of peripherals to provide flexible and high-speed (HS) interfacing and on-chip programming resources.
… [see earlier]
• Three universal asynchronous receiver/transmitter (UART) modules as serial-communication interfaces
• One UART + IrDA SIR up to FIR + TV remote control interface (CIR)
• McBSP module to provide full-duplex serial communication between the OMAP and other applications chips and codecs
• Five HS I2C™ controller modules; four of them are general-purpose modules with rates up to 3.4 Mbps, and the fifth one, in the PRCM module, performs dynamic voltage control and power sequencing with an external power IC.
• HDQ™/ 1-Wire® – Benchmarq HDQ and Dallas Semiconductor 1-Wire protocols interface
• Two HS MMC/SD/SDIO modules with 8-bit data bus interface, that can act as an initiator on L3 interconnect thanks to an embedded DMA
• Three HS MMC/SD/SDIO modules with 4-bit data bus interface
• Six general-purpose input/output (GPIO) modules with 32 I/Os each
• One keyboard controller, which supports up to 9 × 9 matrix keypads
• One MIPI SLIMbus interface
• Four multichannel serial peripheral interface (MCSPI) modules
• One HS universal serial bus (USB) On-The-Go (OTG) module with embedded PHY, compliant with the USB2.0 (up to 480 Mbps) standard for HS functions and with the OTG supplement
• One HS multiport USB host module, which can be used for interchip connection or with an off-chip transceiver. It is compliant with the USB2.0 standard. The USB host module allows communication with USB peripherals with data rates up to 480 Mbps for HS, up to 12 Mbps for full-speed, and up to 1.5 Mbps for low-speed.
• One full-speed USB module compliant with the USB1.1 standard for full-speed functions
• One MIPI high-speed synchronous serial interface (HSI) module with two full-duplex serial communication interfaces. It is used for communication between the OMAP device and an external device, with data rates up to 192 Mbps for transmission, and up to 225 Mbps for reception. The MIPI HSI supports 16 logical channels on each destination (RX/TX).