最近有两个产品的发布标志着关于SoC结构的考虑来到一个交叉点。iPhone，站在长久以来以硬件模块为导向的传统设计的尽头，开始远离过去；而来自Mobilygen公司的H.264高质量类（High Profile）编解码器芯片，源自不同的传统观点也有可能会走向一个不同的终点。某种程度上讲，这两个路标不仅代表着它们在结构上的不同传承，也代表着它们公司的演化方向。

　　首先看一下万众瞩目的iPhone。由于苹果公司想要保持些神秘感，因此iPhone只有部分的内部细节已经确定。据报道iPhone的核心是来自三星公司的SoC，由一颗ARM-11外加一系列的硬件模块来处理手持设备的主要功能：语音和视频的回放；基于手势接口的高动态触摸屏显示，一个类似的动态图形用户接口；一个2百万像素的相机和一个WiFi接口。

　　再来看一下Mobilygen公司的EnViE视频编解码器。它的大部分功能模块都是独立的，每一个都有它们自己的本地内存和ARM处理器；例如（虽然不是很确定）计算模块部分涉及到的基带处理器会是一个中等规模的ARM-11外带DSP扩展，WiFi模块需要一个ARM-9级别的核以及一些硬件协加速器，具有低运算负荷的功能，例如音频、蓝牙和系统控制模块都有自己的ARM-7核。

　　这些处理器中只有应用处理器是多功能的，它需要运行用户接口代码，与加速器一起处理图形，为相机模组做图像处理以及在空闲时间执行应用软件。当设计资源紧张时，这种结构甚至会要应用处理器来做像素级的信号处理，而这个工作通常是由专用图像信号处理核来完成的。但是这种低成本的技巧会影响相机的相应时间和帧速率，而且只会在低分辨率时有效。

　　这种由独立模块来组建SoC的方法有很多的优点。比如，它可以让系统集成工程师通过来自外部的授权模块完成设计，而不用找很多高手自己开发。对于这种组合设备例如iPhone，以及相对比较轻技术的OEM比如苹果，这具有很显著的优点。对于有紧凑周期的项目它同样有明显的优势，比如iPhone在用三星取代PortalPlayer作为SoC供应商时面临的时间问题。

　　这个优势的一个很大部分在于功能模块的独立大大简化了系统级的建模。除了共享资源例如DRAM，不必再去考虑并给用户场景的最坏情况建模。

　　另外，通过提前定义用户场景，可以在大部分的时间内要SoC的大部分不仅处于空闲甚至休眠的状态。因为iPhone本质上是个封闭的系统，所以苹果在电源管理上有很大的优势。比起采用通用可编程器件，他们可以实现更高的电源效率。

　　作为对比，来看最近发布的EnViE，来自Mobilygen公司的H.264视频编解码芯片SoC。从某种程度上讲，iPhone系统芯片和Molilygen CoDec芯片在系统框图上有着显示的相似点-由不同用户接口围绕的神秘核芯片，精心设计的外部DRAM通道。同样地，在功能上每个芯片都面临接口服务、系统管理、数据传递以及硬实时任务的组合。当然，两个芯片在细节上千差万别。

　　Mobilygen考虑视频CoDec的出发点是抽象算法和软件实现，而不是SoC的设计。它的核心不是独立功能模块的群集，而是两个实时多线程处理器。多线程的结构使得核可以在同一CPU上处理来自不同功能的一系列任务，实现每个任务的硬实时需求。它也使得CPU可以容忍内存延时，因为核可以在一个周期内转换线程。

　　有趣的是，这意味着CoDec核的硬件模块框图（一个CPU对，围绕着数据交换的一些加速器集群）完全不同于功能模块框图（更像是三阶的流水线）。

　　在很低功耗水平的情况下，不用将很多负荷丢给一个相对复杂的结构去做H.264编码和解码，这种情况与传统的用独立硬件模块去进行系统设计有很大的不同。

　　或许这样的结构来源于把系统看作是软件任务而不是硬件模块。SoC（两个CPU核，一个处理用户代码的ARM-926以及一系列的硬件加速器）的工作是提供一个可将任务动态映射的灵活结构，而不再是对每个任务都无法共享资源的固化平台。理论上讲，这样的结构在硬件使用上更加有效，在功耗方面也更加出色。

　　理论上，每种结构都可以完全利用到功耗管理的最先进理念：电压岛、动态节电以及动态电压频率调整。但是实际上，SoC的真正设计者能实现的技术有限。另一方面，多用途核的方式将大部分的任务交给两个CPU，而应用者可以根据需要进行功耗管理。

　　我们是否可以说SoC设计来到一个交叉点呢？在这里采用功能独立模块的方式逐渐被抛弃，而将动态任务分配给通用计算阵列的方法受到青睐。这么讲也许为时过早。但是看看这两颗芯片，我们不得不做这样的考量。

附英文原文:

　　Two recent product announcements nicely mark a crossroads in SoC architectural thinking. The iPhone, standing at the end of a long tradition in hardware-block-oriented SoC design, points aloofly into the past, and an H.264 high-profile CoDec chip from Mobilygen, coming from a very different tradition points into a possibly very different future. In a way, the two fingerposts not only indicate the heritages of their respective architectures, but the evolution of their companies, as well.

　　Let’s begin with the vastly over-exposed iPhone. There are few certai   
n details about the internals of the device, because Apple tries to maintain a level of secrecy—in what is otherwise known as a profession that would warm the heart of Dick Cheney. But a few points are relatively well-established.

　　The heart of the iPhone is reportedly a Samsung-designed SoC. The chip includes a significant application processor, reputedly a big ARM-11, surrounded by a number of hardware blocks to handle the handset’s major functions: audio and video playback, a highly dynamic touch-screen display with the beginnings of a gesture-based interface, a similarly dynamic graphics user interface, a rather clunky 2 Mpixel still camera and a reputedly quite competent WiFi port.

　　Mobilygen’s EnViE video CoDec Most of these functional blocks are autonomous, each comprising its own local memory and its own ARM processor. For example—though not for certain, as even off-the-record sources are very careful around the long arm of Apple’s retaliatory tendencies—the computing loads involved suggest that the baseband processor would need to be a modest-sized ARM-11 with DSP extensions. The WiFi block would require an ARM-9-class core along with supporting hardware accelerators, and functions with lower computing loads, such as the audio engine, Bluetooth block and system control block, would each have an ARM-7.

　　The only one of these processors that would be in any way multifunction would be the applications processor, which would be called upon to run user-interface code , work with an accelerator to do graphics, do the image processing for the camera module, and in its spare time run applications software. If the design were running out of budget, the architects might even call on the applications processor to do the pixel-level signal processing normally done in a dedicated image signal processing core. But this would be a low-cost trick that would harm camera response time and frame rate, and would only work with limited imager resolutions.

　　There are very substantial advantages to this approach of assembling the SoC from autonomous blocks. For one, as ARM mobile segment manager James Bruce points out, it allows the system integrator to license completed—and therefore, presumably, verified—modules of the design from outside, rather than having to gain the expertise to do the implementation in-house. In a converged device such as the iPhone, and in a relatively technology-light OEM such as Apple, this has distinct advantages. It is also an obvious advantage in a program with a compressed schedule, such as the timeline the iPhone reportedly had after Samsung was selected to replace PortalPlayer as the SoC vendor.

　　A huge part of this advantage is that autonomy of the functional blocks vastly simplifies system-level modeling. It is not necessary to understand what worst-case use scenarios are or to model them, except for shared resources such as DRAM. Hardly any real-time tasks have to concurrently share a CPU core with other high-priority tasks, so much of the uncertainty in interrupt response, real task-switching latency, and priority assignment evaporates, leaving clarity.

　　In addition, by defining use scenarios beforehand, it is possible to not just idle but power-down large sections of the SoC most of the time. If the user is just listening to tunes, or just squinting at a video clip, much of the rest of the system can be powered off, leaving only enough interfaces alive to stream the media data into the handset and keep a watchful eye over the cellular link.

　“Apple has a huge advantage in power management because the iPhone is essentially a closed system,” Bruce observed. “They can literally try all the allowable use scenarios. That will always give a better power profile than they could achieve with a general-purpose, programmable device.”

　　In comparison, consider a recently announced Mobilygen EnViE, an H.264 high-profile, high-definition video encoder-decoder (CoDec) SoC. In some ways the block diagram   
s of the iPhone system chip and the Molilygen CoDec look remarkably similar—a core of secret sauce surrounded by every interface you could need for a variety of use scenarios, and a carefully crafted pipe to hard-pressed external DRAM. Functionally, as well, each chip faces a combination of interface servicing, system management, data streaming and hard real-time tasks. But of course in detail the two chips differ entirely.

　　Mobilygen started life thinking about video CoDecs in terms of abstract algorithms and software implementation, not in terms of SoC design. That watermark remains in the company’s architectural approach. The heart of the Mobilygen chip is not a cluster of autonomous functional blocks, but a pair of proprietary real-time multi-threading processor cores, according to Mobilygen CTO Sorin Cismas. The multi-thread architecture allows a core to handle a mix of tasks from different functions on the same CPU, meeting hard real-time deadlines on each task. It also allows the CPUs to be very tolerant of memory latencies, because the cores can simply switch threads—in one cycle, by the way—on a cache miss.

　　Interestingly enough, this means that the hardware block diagram for the CoDec core—a pair of CPUs and some accelerators clustered around a data switch—is entirely different from the functional block diagram, which would look more like a three-stage pipeline.

　　Without loading too much freight onto what is, after all, a rather specialized architecture to do H .264 encoding and decoding at low power levels, it is worth observing that this represents a very different approach to system design from the autonomous hardware block school. Rather than dealing with system dynamics by isolating code streams from each other, it blends and centralized code execution, and ensures real-time performance by analysis, not overdesign. There are not several CPUs powered down on the chip during normal operation.

　　Perhaps such an architecture does come from thinking of the system not in terms of hardware blocks, but in terms of software tasks. The job of the SoC—with two CPU cores, an ARM-926 for user code, and a variety of hardware accelerators—is to provide a flexible fabric onto which the tasks can be dynamically mapped, not to provide a fixed site with unshared resources for each task. In theory such an architecture can be more efficient in its use of hardware. And, again in theory, it can have significant advantages for power management, as well.

　　On paper, either architecture can fully exploit the most advanced ideas in power management: voltage islands, dynamic power-down, and dynamic voltage-frequency scaling. But in practice, ARM’s Bruce observed, real SoC designers can go only so far with these techniques. Dynamic voltage-frequency scaling using ARM’s Intelligent Energy Management architecture is a formidable tool, but it is also formidably difficult.

　　“There’s always a silicon penalty for voltage islands. You have to weigh how far to go,” Bruce said. It would be impractical for most design teams to attempt it on more than the central ARM-11 processor in our hypothetical iPhone SoC. That leaves less effective and more response-impacting techniques, such as clock gating and power gating, for the other functional blocks in the chip. And it creates real issues for memory structures outside the CPU core, since at the geometries we are assuming here, RAM arrays leak a lot of current and to need very close attention for power management.

The multi-use core approach, on the other hand, puts the vast majority of the activity in two CPU cores that can be power-managed to whatever extent the implementers deem necessary. The system can dynamically control CPU core voltages and frequencies based on instantaneous task loads, or even based on pending real-time deadlines. And it centralizes the critical caches and scratchpads where they can be managed by one energy-management and error-correction block. Mobilygen doesn’t appe   
ar to be going quite this far, but their power figures -- such as 500 mW for a 1080i high-definition encode operation -- suggest they are quite a ways along this path.

　　Is it fair to say that we are seeing a crossroads in SoC design, with functional autonomous blocks gradually being abandoned in favor of a task-based approach, in which dynamic tasks are allocated across a more general-purpose computing fabric? It’s probably too early to tell. Dynamic fabrics and even multicore SoCs may turn out to be a dead end, undone by the difficulty of dynamic system performance modeling. Or it may turn out that the functional-block approach has overwhelming advantages in some applications. But looking at these two chips, one can’t resist the urge to speculate.