在DM642时代，是“一招鲜，吃遍天”。只有一颗处理器，无论客户做多少个产品线，多少种产品，只用维护一种开发环境和软件，只用保持为数不多的一个BOM 清单即可；可是到了达芬奇时代，DM644x算法买不起，自己做吧，还没做完，DM357出来了。跟进 TI的烈士们，累的跳楼的心都有了……

序：

芯片是产业链上游重要的一个环节，一颗小小的芯片具有极高的技术含量和价值，半导体行业每年都会有一个各大厂商营业额的排名，除去2009年，常年盘踞在前三名位置的分别是英特尔，三星半导体和德州仪器(TI)，英特尔凭借的是桌面处理器，三星半导体凭借的是其全面的存储器产品线，TI则是凭借模拟器件，嵌入式处理器和无线半导体这“三驾马车”。(注：DLP应隶属于光电器件，所以未计入)

终端是产业链中上游重要的一个环节，终端厂商用芯片设计出嵌入式硬件，并且基于该硬件开发相应的嵌入式软件，从而构成一个完整的嵌入式终端产品，形象的说就是一块电路板套一个外壳，这里面最重要的一个核心价值的产生就是附加在嵌入式可编程器件上的软件，成为嵌入式软件。

系统是产业链中下游重要的一个环节，系统厂商通过平台软件使得多个嵌入式终端通过互联网进行信息的传递，从而为最终用户提供产品和服务。如在安防市场，视频服务器(DVS)，硬盘录像机 (DVR)网络摄像机(IPNC)就是三种典型的嵌入式终端产品，平台软件则可以通过互联网和局域网管理多个嵌入式终端产品，形成一套基于视频单工传输基本功能的监控系统；如在通信市场，专用视频会议终端配合系统集成商提供的平台软件和MCU可以形成一套基于视频全双工的多点视频会议系统；如在手机市场，iPhone就是一种嵌入式终端产品，而苹果在线商店就是一个平台软件；如在广电市场，机顶盒就是嵌入
式终端产品，结合运营商提供的云服务平台软件就可以玩3D游戏。

结合嵌入式市场产业链关键构成因素之后，其产业系统模型可以抽象为：

嵌入式产业系统 = 芯片 + 嵌入式终端 + 平台软件

2005年，TI 在C6455的1.2GHz高性能DSP处理器之后，嵌入式处理器部门(DSP-Systems)的整体策略开始转变，即由以DSP架构处理器为主导的垂直行业市场战略向以ARM架构处理器为主导的通用行业市场进行战略转型，率先推出了代号为DaVinci的TMS320DM6446处理器。该处理器采用了ARM+DSP+CP(注：CP即Co-Processor协处理器)的SoC架构，其中ARM采用了297MHz的 ARM926EJ-S内核，DSP采用了594MHz的C64x+内核，CP是一个可以支持视频和图像编解码以及其它常用处理算法的 VICP(Video-Image-Co-Processor)加速器。很多观点认为DaVinci其实在技术上并无创新，因为TI的无线半导体部门的OMAP处理器以及行业市场的DM270处理器早已经有了类似的架构，但笔者认为，达芬奇处理器最具革命性意义的就是它的全平台开放性，不同于用硬件直接做多媒体加速的应用处理器，达芬奇处理器提供的ARM，DSP和VICP是三个全部开放且可编程的内核。达芬奇技术的核心其实并不在于硅片本身，而是基于 Linux的那套软件框架，它把一个基于多媒体应用的嵌入
式软件抽象为应用软件和算法软件，采用 CodecEngine框架组件规范了算法软件的开发标准(xDAIS)和统一接口(xDM)，应用软件通过CodecEngine来调用算法软件，在这个层面上，应用软件只运行于Linux之上，并不关心 Linux运行于何种处理器内核上，算法软件被CodecEngine统一管理，所以应用软件也无需关心算法软件运行于何种处理器内核上。用CMEM组件来管理DSP和ARM之间的共享内存，用DSPLink把DSP 和ARM之间的通信模拟成一个类似于Linux多进程之间的RPC(Remote- Procedure-Call)，这其实是一件非常好的事情，可以使得DSP算法工程师和ARM应用工程师并行工作而又确保了最后软件集成的统一规范。

虽然这一次，TI有专门的商用 Linux开发商MontaVista为DM6446定制开发的内核，有全球多家第三方合作伙伴如Ateme，Ittiam，Ingenient 开发的高性能Codec，有中国本土著名IDH时代飞腾提供的RMVB播放器解决方案，但是在2006 年，DM6446在通用市场的推广之路却并非一帆风顺，因为DM642的客户已经习惯了在Windows操作系统下一个名曰CCS的集成开发环境里，写代码、编译、仿真、下载到目标板跑程序，可是突然让他们面对陌生的Linux系统，通过敲写命令行去编译代码，使用vi写代码，安装一堆Linux下的LSP，文件系统，交叉编译环境和DVSDK后还得配置一堆环境变量和路径，才能勉强运行一个例程？OMG！几乎所有的DM642使用者都发出了不可思议的惊叹，原来世界还有如此“落后”的开发方式和文本编辑器。

试想一下，如果那个时候TI能够基于Eclipse推出一个类似于GreenHill的IDE那样的SoC集成开发环境，使得DM642的用户可以无缝过度到DM6446，那应该是怎样一种幸福？难过的事情并不止于此，层出不穷的内核Bug和匮乏的独立开发DSP端算法的资源可是苦了做产品的企业，光是一个Audio OSS全双工的Bug就愣是N个月没有给出完全搞定的Patch，那个时候可真是一个内核升级的Patch都十分抢手，更别说拥有Linux下的 cgtools和dspbios安装包可以笑傲江湖，如果谁再有了DVSDK，那简直可以仙福永享，寿与天齐了。

那个时代，是一个DSP和VICP依然属于行业寡头的时代。

所谓兵马未动，粮草先行。如果把芯片比喻成兵马，那开发工具就是粮草，TI应该同步推出基于Eclipse的双核集成开发环境替代CCS，笔者猜想TI刚开始是想拉动一票业内公司构建一个完整的达芬奇处理器生态环境，像IDE，Codec，OS都找第三方合作伙伴定制，但是要知道，拉人家入伙不是错，入了伙客户不买单那就是天大的麻烦，结果别说 IDE和OS卖出去的寥寥无几，就连Codec也是评估的多，买单的少，全中国达芬奇的粉丝们都在日夜赶工的定制有中国特色的 Codec......

在TI推出了DM6446这颗旗舰产品之后，又陆续推出了DM6441，DM6443，DM6446低频版本和工业级版本等处理器。这里面不得不说的一个公司就是时代飞腾，这是笔者很欣赏的一个公司，在DM6441的杀手级应用里，时代沸腾的MP5方案可谓是曾经风光一时，在没有硬件RMVB解码器的时代，DSP再一次展现了可编程的魔力，遥想当年，华旗推出的基于DM6441 的高端MP5产品也是名噪一时，后来，时代飞腾又基于DM6441推出了网络电视一体机的方案，但是DM6441的价格居高不下使得这个曾经是 TI阵营王牌IDH的公司彻底转向Telechips的平台，笔者在时代飞腾的一个朋友抱怨到，TI一颗芯片都赶上别人的一个BOM了。那个时候我就在想，究竟怎样的附加值和商业模式才能击碎消费市场产业链的利润“微笑曲线”，还是终究在消费市场做IDH就是一个利润夹缝中苟延残喘但又创造着将冰冷的芯片变成有生命力产品奇迹的商业行为？

在第一轮达芬奇热还未褪却之时，TI又推出了由十余种处理器构成的DM643x家族，这完全可以看作是DM644x家族去掉ARM内核和VICP加速器之后的产品，伴随着DM643x处理器出现的还有一个在技术上非常拉风的东西，那就是跑在DSP内核上的Linux虚拟机，这是一家叫做 Virtuallogix的公司做的软件产品，它可以使得DSP支持Linux，这再一次证明了TI想在Linux下统一管理和开发它的全部嵌入式处理器的软件框架战略，在前面提到过DVSDK里的一个组件叫做CodecEngine，它可以使得应用软件通过RPC调用算法软件完成多媒体算法的调用，而不必关系多媒体算法在物理上究竟是运行于ARM还是DSP，在DM6446时代，或许觉得这无非是故弄玄虚，画蛇添翅膀，但当 DM643x上跑着Linux的时候，一切都明朗了，基于CodecEngine开发的应用程序可以无缝的在DM643x和DM644x的 Linux上平滑过渡，这或许就是软件框架的优势吧。

在被DM644x虐了1年后，水深火热的工程师们仿佛终于看到了曙光，终于看到了一颗貌似可以继承DM642衣钵的达芬奇处理器了，终于可以在CCS下继续裸奔着DM642时代的程序了，终于可以在一个彩色的视窗集成开发环境里抛开万恶的xDAIS算法标准写有中国特色的Codec了。于是，DM643x 因为有着比DM642更先进的DSP内核架构和达芬奇响亮的名头走进了千家万户，在终于找到了CSL并且抛弃了虚拟机之后，工程师们又开始抱怨，为什么DM6437只有一个VPFE而并非像DM642有多个VPort呢，这对处理多路视频将是多么的复杂，于是DM643x被打入冷宫，直到DM3xx应用处理器的IPNC大行其道，才被重新定为视频分析协处理器，视频分析软件供应商ObjectVideo将DM643x做成独立的视频分析模块，但阻碍这颗达芬奇处理器涅磐的依然是ObjectVideo昂贵的软件入门费和版税。

不知是机缘的巧合还是天意，在DM643x家族问世后不久，DM648横空出世，这是一个至今已经可以跑到1.1GHz的DSP处理器，它集成了2个千兆以太网接口和5个VPort视频口，DM648才是真正的将DM642精神发扬光大的产品。在万众瞩目下，一个奇怪的事情又发生了，DM648 的开发板居然不是TI御用的Spectrum公司设计的，相关的设计资料也是乏善可陈，至今仍然想不通为什么DM648为何落得如此下场，国内第三方做DM648开发板的跟DM6446简直不在一个数量级。从性能上看，DM648非常适合做多路CIF格式的视频产品，该处理器的5 个VPORT口都是16比特数据位宽，和DM642一样可以同时吃进2路BT656格式的视频，内部采用了DSP+CP的架构，其中CP和 DM644x的VICP是一样的，可以支持8路 CIF格式的
H.264视频编码。

2008年，注定是不平凡的一年。

TI或许已经意识到了在中国这样一个神奇的土地上，有这样一个潜规则，那就是只有硬件是可以卖钱的，硬件上跑的所有东西你都要送我。于是TI开始做出这样一个决定，Linux内核维护从以MonvtaVista为主树转移到以自己维护的内核为主树，逐渐往Community Linux靠拢，彻底摆脱MontaVista；于是TI开始做出这样一个决定，自己做Codec，因为客户听到第三方Codec昂贵的入门费统统都吓跑，自己去做有中国特色的Codec去了，TI可郁闷了，这得做到猴年马月才能量产，于是N多项目胎死腹中。

当TI开始逐步透露要做Codec并且有可能免费的消息后，在业内也算引起了不小的震动，虽然TI一再在每年一度的全球第三方峰会上说他们只是做一些基本功能的Codec以应对其它半导体厂商应用处理器的免费Codec带来的竞争压力，但是，Ateme 还是转向FPGA平台，Ittiam传言准备自己做 ASIC，Ingenient则被Sasken收购，而此时的时代飞腾，则彻底放弃了TI的平台，转向更加经济实惠的Telechips和 Marvell，于是，TI的Codec阵营就在这一年土崩瓦解。

但是事情远比想象的严重，这位行业巨鳄开始全面拉低嵌入式处理器产品配套工具的利润，达芬奇处理器的性能虽然是一路飙升，但是相应开发板的价格确实越来越低，最后TI终于祭出大招，OMAP3530的BeagleBoard以一种社区开源模式面世，所有的硬件设计源文件以及驱动和操作系统都可以从网络社区下载，用于仅需要99美金就可以买到的BeagleBoard开发板，而同年份，合众达的560仿真器跳水到4800一只，BlackHawk又推出仅 199美金的560Plus仿真器，国内几家传统ARM开发工具供应商的OMAP3530开发板价格全部在千元以下，DM642时代高利润的蓝海时代顿时变红，而且还飘着不少第三方的尸体。

令人感到不解的是，进入嵌入式市场的 OMAP3530处理器依然保持着移动市场特有的0.5mm点距和PoP封装，过了好一阵子TI才发布0.65mm点距的硅片。OMAP是TI在移动市场处理器的旗舰产品线，在2008年底推出的OMAP3530集成了Cortex-A8内核，C64x+的DSP内核和硬件加速器，并且还具有PowerVR的图形加速器。虽然血统不同，但OMAP3也可以粗略看作是DaVinci架构的低功耗版本，但跟DaVinci不同的是，OMAP3530加强了GPP的性能，削弱了DSP的性能，一个考虑是进一步降低功耗，另一个则是市场因素，达芬奇处理器主要用于做视频压缩的产品，而OMAP3都是面向做视频解码和图形显示的产品，于是国内国外用DM6441做移动电视和便携式播放器的厂商为了保持竞争力又不得不转移到 OMAP3平台上，因为该平台不仅有3D图形加速器，可以做3D导航和玩游戏，还有比DM6441更低的功耗和更强的 GPP资源。在2009年的TI开发商大会上，Cortex-A8内核确实是独领风骚，OMAP阵营的参展商一举压倒了DaVinci参展商，诸多的Android，WinCE独立软件供应商和无线模组供应商开始加入TI的阵营，而TI发布以ARM为主导的产品数量已经开始超过以DSP为主导的产品数量了。

像TI这样的公司，在以DSP架构为主的产品发展时期，结盟了众多第三方助阵，而当以DSP架构为主的产品走到成熟时期，TI则毫不犹豫的踹掉了这些第三方公司(虽是无奈之举但毕竟是不争的事实)，为的就是进一步降低通用市场客户的入门成本，举个例子就是：以前10万美金的Codec入门费对垂直行业的那些寡头算个毛，但对通用市场的客户来说，打死也不会掏钱的。所以，在商场上，只有永恒的利益，没有永恒的友谊，TI这么做是战略转型的必然结果。

为了在高清网络摄像机(HD-IPNC)市场拔得头筹，TI在2008年初率先推出了可以做到720P30实时MPEG4编码的DM355处理器，和 OMAP3一样，DM355处理器带有浓重的行业寡头特色，它原本是一颗做数码相机的处理器，所以拥有2个SD卡接口却没有EMAC，大概是柯达的数码相机并没有连网的需求吧，于是Spectrum通过DM355的EMIF总线接口扩展了百兆以太网接口，但这还远远不够，DM355平台为了降低成本，抛弃了DM644x和DM643x家族采用Nor flash作为启动存储器的方案，改用SLC NAND闪存存放启动代码和文件系统。

为了进一步降低成本和推进市场增长，TI选择了Appro公司为其定制高清网络摄像机参考设计，在这一点上，TI的思路是非常正确的，因为在高清分辨率下，CCD传感器非常昂贵，而CMOS传感器像原尺寸又做不大，导致本身在低照度下就就性能欠佳的CMOS传感器的成像质量在高分辨率时是差上加差，于是TI在DM355处理器内部集成了一个叫做ISP的硬件影像处理单元，可以直接支持RAW格式数据的处理，我们姑且管这一块叫做影像预处理，有了ISP，DM355处理器就可以无缝的对接各种图像传感器了。再来看看图像传感器供应商，Aptina的传感器一般叫做Sensor，可以直接输出RAW 格式的数据，Ovt的传感器一般叫做SoC，内置了ISP，低分辨率的产品可以直接输出YUV的数据，高分辨率的产品也是输出RAW格式数据。不知是因为TI和Aptina高层的关系很好，还是为了彰显DM355处理器ISP的英明神武，在Appro的这个参考设计里选择了Aptina公司的 MT9P031 5MP传感器，专门使用DM355的ISP开发了针对MT9P031 CMOS图像传感器的影像预处理算法，于是变形
金刚合体，在2008年初，万众瞩目的 720P高清网络摄像机参考设计闪耀登场。

TI认为自己的这番努力已经秒杀了掌握最先进ISP技术的日系厂商，成功的把DSC的成像技术移植到了IPNC，势必会引爆一个巨大的市场，高清视频，极低的成本，成熟的ISP技术，甚至连镜头和外壳连带完整的硬件参考设计都已经准备就绪，整个BOM成本不到40美金，而整个参考设计除了提供全套硬件源文件外还有全套的Linux参考软件，整套方案售价仅为995美金，这个就是Appro在2008年TI开发商大会推出的DM355高清网络摄像机参考设计，但是请注意，这仅仅是一个参考设计，而不是一个深圳模式下的解决方案。

在深圳，只有MTK那样的才叫解决方案，英文叫Turn Key，套用大腕儿里的一句话，什么叫方案知道么？只要注入一笔钱，再找个工厂一量产，产品和利润就出来了，我们做方案的口号就是，不求最好，但求最快！

是的，当时笔者还真是听说深圳有人直接拿Appro的这个参考设计去工厂生产，结果自然是无法量产，投资失败，因为Appro此次的“方案”并非 MTK的 “方案”之含义，准确的说仍然只是一个参考设计框架，而不是一个立刻可以被量产的产品。为了推广DM355处理器，笔者也曾多次前往深圳，记忆颇深的是拜访一家做网络摄像机的客户，研发总监亲自接待，说：“你们(其实笔者非TI的人)的这个DM355压缩效果不行，我接高清电视看了，都是马赛克。”笔者顿觉惊诧莫名，问道：“您是用复合视频接到高清电视上看的？”该总监道：“正是。”笔者顿觉无语，须知复合视频怎可传递高清视频信号？好吧，遂指出该总监 “疑惑”，为DM355正名，继而该总监又说到：“我们现在用其它方案D-In，网络摄像机量很大，我们只要每台挣1个美金就可以开始跑量！”这就是一个非常典型的深圳市客户，他们崇拜的是MTK式的神话，他们需要的是一个可以马上量产的方案，他们需要的是一个可以带动生产力和现金流的Turn-Key- Solution，他们的特点就是简单快速，薄利多销。

从技术角度看，DM355的功耗和性价比还是非常不错的，采用了0.65mm的点距，内建了ISP装置得以处理Aptina的5MP像素传感器的 RAW格式数据，该传感器使用了2x2的binning模式来增强成像质量，可以输出720P30的MPEG-4视频流。但遭人诟病的是，DM355内部的ISP行缓存不够长，在做5MP抓拍的时候，需要2-Pass才能完成处理，2-Pass就是先把图像采集到内存，上半边通过ISP处理一下，下半边再通过 ISP处理一下，也正巧了，赶上那年交通行业的相机都要5MP抓拍，惹得全国上下用DM355做相机的厂商怨声载道，那能搞出5MP抓拍的都是神仙？妖怪？

如果DM355定位于启动低成本高清IPNC市场的引信，TI是绝对应该找一家平台软件供应商推系统方案的，Appro的参考设计和深圳模式是不搭调的，也错过了山寨高清网络摄像机的第一桶金，后来的 DM365和DM368时代，Ambrella和MG3500已经可以在这个市场分到一杯羹，TI人无我有的战略优势丧失殆尽，顿时变成了人有我优......

2009年春暖花开之时，TI果然毫不迟疑的推出了能支持H.264 720P30压缩的DM365达芬奇处理器，该处理器可以认为是DM355的完善版本，除了更新了ISP之外，DM365使用了和DM355 相同的 ARM926E-JS内核，使用了DM355的MJCP硬件加速器，这个加速器可以做MPEG4的编解码和JPEG的编解码，同时加入和 DM6467的 HDVICP0这个可以支持H.264硬件编解
码的加速器，构成了DM365的基本架构，当然，植入一个EMAC弥补DM355 的鸡肋还是不难的。这里面请注意，TI在HDVICP0上一直没有MPEG4和JPEG的Codec，虽然HDVICP0号称可以支持 MPEG4，于是就只好来一个组合拳，可以说 DM365是DM6467和DM355联姻的结晶。但是光720P还不够，DM365的弟弟 DM368在2010年也会出世，要问怎么做到1080P的，超频，超频！！！

DM36x既然出来，Appro自然也不会闲着，在2008年以摧枯拉朽之势忽悠了众多客户之后，2009年继续推兜售他们的ISP算法，这次不光是 Aptina的传感器，Sony和Ovt的传感器也用上了。说到传感器，这里有一个有趣的现象，在Aptina剥离Micron之后，TI开始很低调的做一种基于CMOS技术的宽动态传感器产品线，那么自然可以大胆推测，凭借TI的野心和实力，既然想把网络摄像机做到白菜价，那么它就得把 CMOS传感器和 DM368做到一颗芯片里，真正的实现“俺们也就走个量，一个只挣1块钱”的宏伟蓝图。

从技术角度看，DM355处理器的MJCP是由DM644x/DM648的VICP演变而来，而DM36x的集成度要比DM355强一个档次，不仅集成了 AudioCodec，还能在单通道视频接口VPFE上做多路视频流的Demux，NAND闪存控制器也从DM355的1-bit ECC变成了4-bit ECC，而且还支持硬件人脸检测功能，同时解决了ISP内部行缓冲不够的问题，终于可以支持1-pass的高
分辨率图片抓拍。在参考设计资源上和 DM355不同的是，DM365除了Appro提供的IPNC参考设计，还有UDWorks公司的DVR参考设计，该参考设计可以支持8-CIF或者2- D1的视频压缩，使用了一颗TI同步推出了高性能四通道视频ADC芯片TVP5158，大概是看到 Techwell在DVR市场赚了不少，TI也开始做多通道的视频ADC产品，刚想说那Techwell的市场应
该会让出一部分，就听闻 Techwell以3.7亿卖给Intersil了......

DM6467T作为DM6467家族的最高端产品，拥有近乎 1GHz主频的DSP内核，500MHz主频的ARM926E-JS内核以及2个HDVICP硬件协处理器，其中HDVICP0可以支持 H.264/VC-1/MPEG-4高清编码，HDVICP1可以支持H.264/VC-1/MPEG-4 /MPEG-2高清解码，而该处理器显然和任何一款DaVinci家族的处理器不同，它的VPIF决然不同于VPFE和VPORT，该端口仅支持嵌入同步的视频格式，但是却可复用为TS流传输或接收模式，可以非常方便的支持DVB-ASI接口，这是一颗明显带有广电行业特色的处理器，它可以单芯片实现MPEG2到H.264的实时转码功能，并且支持千兆以太网接口，而且一直号称可以支持1080P60 H.264高清编码

TI 这种从DSP单核心架构到DSP+ARM+硬件加速器SoC架构再到ARM+硬件加速器SoC架构的转变过程非常之快，在不到3年时间内先后快速推出多种处理器，而且还都是先找寡头买单，再挪到通用行业市场。从某种意义上说，观望的客户会引起“审美疲劳”，跟进的客户会发现“投资贬值”，也就是TI并没有很好的保护客户对它的投资。

在DM642时代，是一招鲜，吃遍天，只有一颗处理器，无论客户做多少个产品线，多少种产品，只用维护一种开发环境和软件，只用保持为数不多的一个BOM 清单即可；可是到了达芬奇时代，DM644x算法买不起，自己做吧，还没做完，DM357出来了，那就用DM6467做720P产品，结果DM365出来了，只好用DM6467做1080P产品，结果DM368又呱呱坠地；如果刚用DM6441做完D1 H.264网络摄像机，DM355的720P MPEG4又得换一套DVSDK，还得琢磨0.65mm的点距，从644x的NorFlash换成SLC NAND；1年后，没辙，继续跟进DM365，这时候估计已经比放弃 DM355，专盯着DM365的客户要慢了几个月了；君不见DM365官方开发板上辉煌的电源方案足可以引多少英雄豪杰竟折腰(用了十几种)；相比于Ambrella的IPNC方案和海斯的DVR方案，TI的参考设计又明显缺乏成熟的“山寨化”软件；纵观跟进TI的烈士般的公司们，累的跳楼的心都有了，光是那一套套不一样的DVSDK，一堆堆形形色色的Patch，就已然头昏脑胀了......

TI在2009成功收购了Luminary，补强了MCU的产品线，形成了以 MSP430，Cortex-M3和Cortex-A8为核心的高中低档全线 MCU产品线，初步实现了硅片产品的战略布局。在软件方面，抛开MontaVista之后，Linux全面转向Community阵营，IDE转向基于 Eclipse的CCS4.0，至此，算是基本完成了由DSP为核心的处理器架构向以ARM为核心，DSP，硬件加速器为辅的处理器架构。TI的网站在 2010年也做了结构性的调整，Processor下面出现了ARM，DSP和MCU三个板块。

DSP这种处理器架构还能保持多久的生命力是一个值得探讨的问题，嵌入式处理器市场的竞争本质还是架构之争。有一个观点是任何一个处理器设计公司都不会同时维护两种架构的处理器产品，如Intel公司先是改造ARM架构，做出XScale处理器，但是后来却卖给了Marvell，为的就是统一桌面处理器和嵌入式处理器的架构，后来推出的Atom等一系列处理器都是基于x86架构的瘦身产品，且不说Marvell吃进Xscale后赚的盆满钵满，Xilinx 也将在Spatan-6和Virtex-6之后统一自己FPGA架构。TI又何尝不想如此，但是因为它的产品线过于庞大，也就注定需要很长的时间了。首先在C64x和C64x+的DSP内核架构之后，又推出了C674x+内核架构，该架构统一了浮点DSP和定点DSP内核；其次在 DM8168和OMAP4处理器上，TI则会统一硬件协处理器的架构，即OMAP4和DM8168都采用IVA-HD这种相同的硬件加速器；至此，TI在 SoC上已经形成了C674x+Cortex+IVA-HD的统一架构SoC雏形。

记得ADI公司早在若干年前就关闭了以色列的TigerSharc设计中心，其理由是，该处理器已经登峰造极，没有再发展的必要；在桌面处理器市场，主频提升早已遭遇瓶颈，多核心时代正在到来，而ARM此时已经不声不响迈入双核2GHz的Cortex-A9时代。TI的DSP也是如此，C6000 架构已经成熟多年，1.2GHz似乎已经是不可逾越之极限，于是2009年TI发布了3个1.2GHz核心的高性能多核DSP处理器 TMS320C6474，这也是一颗从垂直行业市场拿到通用市场的处理器(TI开始晒家底儿了？)，随后又发布了拥有6个700MHz内核的 TMS320C6472多核DSP处理器，但恐怕由于功耗的原因，基于65nm工艺的C647x系列很难再有突破。多核心DSP未来的道路确实很艰难，因为它已经处于一个非主流的位置，虽然不排除在更先进的工艺节点上植入更多的DSP内核甚至是Cortex-A9内核完成统一处理器架构和软件框架的疯狂构想。
  
在Intel收购风河公司，Xilinx和ARM结盟，Altera和 MIPS联姻，Winter联盟被ARM和Google瓦解之后，嵌入式市场就要好戏连台了。

相关阅读：

英特尔8.84亿美金收购风河，全面布局移动互联网市场

Xilinx和ARM结盟：高性能嵌入式设计的加速器

MIPS科技向Altera公司授权MIPS32架构

Intel支持Android之举打乱Microsoft阵脚

微软意欲搭上 ARM


在Intel没有想明白是不是像ARM那样进行IP授权来运营Atom的时候，请将目光移向ARM阵营，Altera 其实在很早以前就有过一款集成了ARM7硬核的FPGA产品，笔者非常奇怪为何Altera要做这样一个看起来并不十分明智的产品，须知在那样一个年代，一个昂贵的，功耗很大的FPGA 去联姻一个廉价的，功耗很低的RISC究竟意义何在？而Xilinx在SoPC的战略上无疑是成功的，它选择了同样昂贵，功耗很高但同时性能也很高的 PPC硬核，从Virtex-II一直到Virtex-5的产品中都可以看到集成PPC 硬核的产品，但是这一切都将在28nm节点工艺改变，在28nm技术上，Xilinx选择了高性能低功耗的工艺，而Altera则选择了更高性能但高功耗的工艺。因为在28nm，Xilinx将植入Cortex-A9硬核处理器，创造真正的低成本，低功耗的SoPC产品，继续向嵌入式市场挺进，试想如果一颗集成了Cortex-A9的SoPC芯片售价15美金，你还会选择相同价位的SoC吗？笔者认为Xilinx选择在 28nm节点统一产品架构是因为此时FPGA的功耗和成本跟PPC已经不再匹配，ARM才是最好的选择。

如果 TI的嵌入式处理器产品线架构是一个线性空间，那么它的正交基是：DSP内核，ARM内核，硬件加速器和通用外设，用公式表述一个TI的SoC定义为：

TI SoC = a * DSP + b * ARM + c * Accelerator + d * Peripheral

而当FPGA在28nm拥有Cortex-A9的双核处理器和标准外设，客户已经可以在功耗和成本都可接受的SoPC上定制自己的硬件加速器和接口设备，用公式描述一个Xilinx的SoPC定义为：

Xilinx SoPC = a * ARM + b * Customer-Accelerator + c * Customer-Peripheral

一种新的嵌入式处理器架构的诞生或多或少都会引起变革，2005年是TI的SoC，2012应该属于Xilinx的SoPC.
原文链接：
http://jinsuo2007.blog.163.com/b ... romSearchEngine=yes 返回小木虫查看更多