面向移动互联网的SoC

题目很大,需要回答,在此罗列一些自己的观点以备日后反思:

1. 性能为王,功耗需要考虑,成本压力不大。从最近的分析看来,性能为王的思路是合理的,无论是纯粹的本地应用还是基于Web的应用,程序(或者脚本)执行的速度,执行过程中给用户的体验都极其重要。当性能差异较小时,人们会看重兼容性问题。对互联网移动设备功耗的需求已经退居其次了,至少不再是核心竞争力。事实上随着工艺尺寸的不断下降,功耗和成本的压力都有所缓解。虽说65nm以下工艺的NRE费用是一个问题,但芯片设计成本的摊销更应该以出货量,而非死抠芯片面积达成。而出货量就是性能的拼杀。可以把性能看做进攻的长矛,而功耗和成本都是战场上保命的护甲。没有锋利的长矛,呆在护甲的保护下是没有出路的。

有几个例子引用:苹果的A5处理器,芯片面积大约12mm×12mm=144mm2,而Tegra2处理器仅30-40mm2。从成本上来看,苹果没有优势,但真正能赚到钱的芯片还是A5。有比如说Android发力之前的Marvell,功耗控制一直不错,性能也不错。但没有突出的性能优势,结果被Quacomm的Snapdragon的1G处理器彻底挤出了智能手机领域。TI的omap也是一个例子,长时间omap推自己最高端的芯片力不从心,直到最近才不遗余力的推高性能,赢得好的市场份额。

芯片性能来源几个方面:CPU核的性能、DSP的性能、专用加速单元的性能、片上总线和存储设计。

其中CPU核的性能至关重要。核的性能不能简单看做主频的提升或者核心数目的提升,但这两个指标对于现实用户体验来说至关重要。当访存不是瓶颈时,核的主频几乎可以正比于系统的整体性能(比如Milestone工作在550MHz与900MHz的明显差异),而多核对于多线程处理效果的提升更是有目共睹,比如苹果A5与A4的区别。此外还必须关注核的指令集和流水线设计的先进性,先进的指令集设计可以在不牺牲指令密度的前提下大幅提升芯片DMIPS,最好的例子是ARM v7架构与ARM v6TE架构的区别,前者最高可以达到2.5×2 DMIPS,后者仅能达到1.1DMIPS。而先进的流水线设计更是能直接决定系统响应速度、程序循环开销等性能,比如同为ARM v7的Cortex A8与A9。最后核的性能还体现在专用指令的性能上,比如NEON指令集。使用此类SIMD指令可以明显加速系统对UI、Web page以及媒体的渲染性能。

DSP的性能现在也逐渐显现出来,部分不太适合用专用硬件加速又比较牺牲CPU MIPS的操作可以专门用DSP实现,由于其软件编程的难度不大,很多厂商用其实现音频解码甚至部分小尺寸视频编解码,可能较为完美的提供视频通讯、加密解密、压缩与解压缩等常规任务。

专用加速单元的性能在SoC中主要指GPU与VPU。相交而言GPU的意义更大,而VPU的应用场景单一、指标天花板现象明显。最近推出的高兴能应用处理器所集成的GPU性能非常强大,因为大量高兴能游戏需要高吞吐量、高Vertex以及高贴图速率的GPU。特别是在Android3.x系统中,大量的UI渲染以及Web渲染已经移交给GPU,集成一颗高兴能的GPU将让SoC从很多方面获得好处,比如UI体验、完整网页的顺畅缩放、高兴能高分辨率3D游戏体验等等。

片上总线与存储设计。当SoC为了追求高性能时,一般需要解决以下几个问题:每个IP的独自的数据带宽、IP之间数据共享与传递的带宽。为了解决上述问题,片上系统的总线设计必须及保留多层形式,又考虑分布化(局部化)。在数据共享方面还需要高性能的片上缓存支持。

2. 方案设计必须指导芯片设计。在芯片性能设计中存在很多盲点,由于芯片架构确定与最终应用中间的过度太多,每一层都会引入大量的复杂性,最终导致芯片性能设计出现盲点。因此芯片架构设计前期需要开展深入的软硬件协同,认真分析上一颗芯片存在的性能瓶颈。特别需要警惕的是一些表面看来硬件实现简单,性能提升比例很大,但事实上软件根本无法集成的方案,比如没有集成到CPU核内部的加速器在操作系统下的使用问题。

举苹果在处理UI的一个例子。为了提供更好的UI体验,苹果不仅大量借助GPU实现对图形的渲染,还从软件最底层的操作系统核心做起,一层层抠对用户输入的响应时间。而Android底层是基于Linux的,没有人对Linux的实时性做出优化,在Android本身UI系统的底层也没有使用GPU渲染,最后到上层应用还遇到UI渲染过程还不得不时做一些java的垃圾回收事情。也就是在系统的每个层次都没有严格的扣相应速度,这样能做出和苹果竞争的产品就只能寄希望与无比强大的硬件,但付出的将是高昂的价格与较低的使用时间。这里反过来可以看出性能为王的背后一层意思,性能上去了,相对的其他成本反而能降低。

3. 网络应用的需求在未来可能非常巨大。从此前的经验来看,当人们最终需要解决跨平台问题时,唯一的可选方案就是网络。通过浏览器可以较为轻松的绕开操作系统、SoC设计直到CPU架构等不同层次的平台移植问题。特别是在HTML5推出以后,大量可以访问本地外设资源(本地存储设备、重力感应、地理位置以及摄像头等)的API以及可以直接进行UI开发的2D/3D图形图像API(Canvas和WebGL)的释出,程序员可以真正实现一次开发,无限使用的目的。几乎可以无视windows、macos、linux的操作系统环境或者x86、ARM、MIPS的CPU架构。事实上,网络应用的平台性也正在成为人们追逐的热点。所谓平台性是指通过推出基于网页的云解决方案,用户可以被帖附于某套完整环境中,毕竟人们习惯一个相对统一的环境,比如Google的全套服务以及腾讯最近搞出来的webqq等等。

面向网页计算对系统性能的要求没有变低反而变高。无论是各类java script脚本的渲染速度,还是Canvas的2D图形图像绘制,又或者是3D WebGL对本地GPU的使用都需要高性能的SoC(对Flash的支持这个比较难讲,的确当前有大量的Flash开发人员,但确实在某些平台上其性能非常低下,比如macos。而有些平台则根本不支持Flash,比如iOS和Android2.2之前的版本。然而基本上当前Flash可以完成的工作,HTML5协议都支持,又有Google、Apple以及微软的大力推进,个人认为将来网页渲染,应用都应该是基于HTML5的)。而对于SoC设计本身,由于需要非常明确浏览器本身的性能并通过硬件加速,所以事实上与应用更远了一层,也就增加了不确定性。

Advertisements

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s