(一板通)硬件電路设计流程系列方案设计.docx

平台的选择很多时候和系统选择的算法是相关的，所以如果要提高架构，平台的设计能力，得不断提高自身的算法设计，复杂度评估能力，带宽分析能力。常用的主处理器芯片有：单片机，ASIC，RISC(DEC Alpha、ARC、ARM、MIPS、PowerPC、SPARC和SuperH )，DSP和FPGA等，这些处理器的比较在网上有很多的文章，在这里不老生常谈了，这里只提1个典型的主处理器选型案例。比如市场上现在有很多高清网络摄像机（HD-IPNC）的设计需求，而IPNC的解决方案也层出不穷，TI的解决方案有DM355、DM365、DM368等，海思提供的方案则有Hi3512、Hi3515、Hi3520等，NXP提供的方案有PNX1700、PNX1005等。对于HD-IPNC的主处理芯片，有几个主要的技术指标：视频分辨率，视频编码器算法，最高支持的图像抓拍分辨率，CMOS的图像预处理能力，以及网络协议栈的开发平台。Hi3512单芯片实现720P30 H.264编解码能力，满足高清IP Camera应用, Hi3515可实现1080P30的编解码能力，持续提升高清IP Camera的性能。DM355单芯片实现720P30 MPEG4编解码能力，DM365单芯片实现720P30 H.264编解码能力, DM368单芯片实现1080P30 H.264编解码能力。DM355是2007 Q3推出的，DM365是2009 Q1推出的，DM368是2010 Q2推出的。海思的同档次解决方案也基本上与之同时出现。海思和TI的解决方案都是基于linux，对于网络协议栈的开发而言，开源社区的资源是没有区别的，区别的只在于芯片供应商提供的SDK开发包，两家公司的SDK离产品都有一定的距离，但是linux的网络开发并不是一个技术难点，所以并不影响产品的推广。作为IPNC的解决方案，在720P时代，海思的解决方案相对于TI的解决方案，其优势是支持了H.264编解码算法，而TI只支持了MPEG4的编解码算法。虽然在2008年初，MPEG4的劣势在市场上已经开始体现出来，但在当时这似乎并不影响DM355的推广。对于最高支持的图像抓拍分辨率，海思的解决方案可以支持支持JPEG抓拍3M Pixels@5fps，DM355最高可以支持5M Pixels，虽然当时没有成功的开发成5M Pixel的抓拍（内存分配得有点儿问题，后来就不折腾了），但是至少4M Pixel的抓拍是实现了的，而且有几个朋友已经实现了2560x1920这个接近5M Pixel的抓拍，所以在这一点上DM355稍微胜出。因为在高清分辨率下，CCD传感器非常昂贵，而CMOS传感器像原尺寸又做不大，导致本身在低照度下就性能欠佳的CMOS传感器的成像质量在高分辨率时变差，于是TI在DM355处理器内部集成了一个叫做ISP的图像预处理模块，它由CCDC，IPIPE，IPIPEIF和H3A模块组成，能帮助实现把CMOS的RAW DATA（一般是指Bayer格式数据）转成YCbCr数据，同时实现包括白平衡调节，直方图统计，自动曝光，自动聚焦等采用CMOS解决方案所必须的功能，故DM355处理器就可以无缝的对接各种图像传感器了。而海思的解决方案对于CMOS的选择就有局限性，它只能用OVT一些解决方案，因为OVT的部分Sensor集成了图像预处理功能。但是DM355不仅可以接OVT的解决方案，还可接很多其他厂家的CMOS sensor，比如Aptina的MT9P031。所以在图像预处理能力方面，DM355继续胜出。在IPNC这个领域，只要每台挣1个美金就可以开始跑量，所以在那个时代，很少有人会去死抠H.264和MPEG4的性能差异，而且TI已经给了市场一个很好的预期，支持H.264的DM365很快就会面世。所以IPNC这个方案而言，当时很多企业都选择了DM355的方案。有些朋友现在已经从DM355成功过渡到DM365、DM368，虽然你有时候会骂TI，为什么技术不搞得厉害点，在当年就一步到位，浪费了多少生产力。但是技术就是一点一点积累起来，对于个人来不得半点含糊，对于大企业，他们也无法大跃进。DM355的CMOS预处理技术也有很多Bug，SDK也有很多bug，有时会让你又爱又恨，但是技术这东西总是没有十全十美的，能在特定的历史条件下，满足市场需求，那就是个好东西。当然海思的解决方案在DVS、DVR方面也大放异彩，一点也不逊色于TI的解决方案。其它芯片的选型则可以参考各芯片厂商官方网站的芯片手册，进行PK，目前大部分芯片厂商的芯片手册都是免NDA下载的，如果涉及到NDA问题，那就得看个人和公司的资源运作能力了，一般找一下国内相应芯片的总代理商，沟通一下，签个NDA还是可以要到相应资料的。每隔一周上各IC大厂的官方主页，关注一