DIY编程器网

标题: 慎选加速译码解决方案满足不同产品需求 [打印本页]

作者: admin 时间: 2014-10-13 07:44
标题: 慎选加速译码解决方案满足不同产品需求
H.264所内含的先进的编/译码技术，虽能大幅提升压缩率，同时保有视讯质量，对于高画质应用或是网络串流应用，都是相当大的优点，但它是透过复杂的算法完成，这对编/译码器或处理器效能是一大挑战。

其实相关厂商设计视讯压缩技术，大部分已相当有经验，毕竟这个产业并不算年轻，但是过去的经验未必能套用在H.264相关产品加速译码设计上。因为在压缩算法的复杂度上，H.264比目前主流MPEG4来得繁复许多，比起常见的MPEG2技术，则更要复杂近10倍。

这是因为H.264的开发重点，从一开始时即着重在于有效改善压缩效率，而不是去限制实现方案的复杂度，这和过去的视讯标准(MPEG1/2/4、H.261/262/263)在定位上就不一样，这在前章已经有仔细分析。因此H.264编码器的结构与压缩算法，就和以前大不相同。

以过去设计概念来看，流通性译码软件，是最低成本的设计方式，免除许多一分钱一分货的电路与零件，不过因为H.264压缩的复杂度，目前软件解决方案相当少，而且对大多数携带型视讯装置来说，资源需求亦不经济。

因此，最佳方式还是采用硬件最佳化演算架构，尤其是为可携设备提出更低功耗和小尺寸的解决方案，在强化视讯解压缩性能后，还保有体积小、性能稳定、电力消耗更少，甚至成本更低…等优势。

视讯装置包含组件太多单一面向设计无法面面兼顾

产品被要求「俗又大碗」，是所有CE产品的共同宿命。因此，虽然H.264译码采用硬件加速，一定是最佳解决方案的道理相当简单，但实作起来可就不是这么回事，因为这不是单纯的技术考虑。

俗又大碗的设计概念放到产品内，通常是被要求设计出每1种功能都有，但又足以满足差异化的产品，也就是视讯译码功能够强，但其它能力也不能少。

看看目前典型的多媒体设备，所能实现的各种功能，就知道设计复杂度。首先必须满足多媒体，即各种视讯、音讯和影像编/译码标准，例如H.264、VC-1、MPEG2/4、AAC、MP3、JPEG…等，还有重要的无线连结和定位技术，包括天线、射频和基频处理在内的蓝牙、GPS、Wi-Fi、UWB、WiMAX…等。而在游戏导向或是高阶产品，还有3D绘图功能需求，此外语音识别技术也成为一些产品的功能。

这么多的功能，对于视讯播放为主力的产品来说，译码设计当然相当重要，但显然不是唯一。以上各种不同的技术，通常需要各种不同的处理能力以及不同的电路组件。

通常直觉的概念，是以个别零组件对单一任务，例如iPhone就使用多个MCU对应多个功能。但大部分情况下，如果以个别准备的方式来进行产品设计，会因为零组件过于庞杂，最终成品的外型可能相对过大，甚至可能因为组件间的阻抗问题，造成耗电量大增，而如果采用较精密的多组零件，成本又可能直线上升。因此，最佳答案几乎直指整合各种多媒体译码能力的SoC，就成了同时满足系统微缩与省电性能要求的必要手段。

可携式多媒体SoC中，支持所有视讯标准和内容类型，有3种可用方案：硬件加速处理器(H/W Accelerator)、视讯辅助处理器(Video co-processor)和通用处理器(DSP/RISC)。

硬件加速设计简单明了除错难度高也较不具弹性

硬件加速是指，只执行1个特定单一标准的单一功能编码或译码，在设计上具有最高效率和较少的闸数，因为不需要考虑其它用途。但在开发后，不同SoC只有在功能完全相同时才能再使用，例如，当硬件加速器支持以VGA分辨率编码的MPEG4格式时，需要大约15万个逻辑闸，但是要同时具备H.264 Baseline Profile(D1)以及MPEG4译码能力的硬件加速设计，不但整个芯片架构必须重新设计，逻辑闸也会增加到35万。

采用硬件加速器具有的优点，包括整体规模小，因为只需执行固定作业，不包含任何指令处理(存取、译码)，也没有程序内存管理，因此闸数较少，再者因为闸数较少、存取效率高，通常功耗亦较小。在性能上，因为对应专门的硬件路线，所以处理效率也高，执行速度快。

但采用硬件加速的缺点是，例如视讯加速就只能处理视讯，因此如果用硬件视讯加速器时，多媒体中的音讯和语音部分必须由SoC中的其它部分来处理，通常是CPU或DSP，因此需要多零组件。内存方面亦然，在SoC中，加速器专用内存不易被其它组件存取，因此从成本和硅芯片面积的角度上来看，利用效率较低。

此外，多媒体设备不可能只有画面没有声音，因此影音间的同步处理，必须在CPU上进行，也因此增加CPU部分研发需求与整合难度。此外，可能会增加其它零组件的耗能，例如CPU通常需执行算法的信息编码(如CAVLC)，和后续处理(如解锁滤波器)，让CPU的功耗上升，因为又回到CPU并非专门路线的问题。

而在软件升级和除错修复方面，硬件加速器路线无法透过软件升级方法来隔离或修复缺陷，因此一有设计缺陷，通常会导致重新投产、从头来过。对新一代需求来说，在SoC中执行特定任务的硬件加速器，也无法重新利用。

当然，硬件线路加速器，可以设计成兼容多种解编码标准，必会面对前述的一些缺点，但是整合的功能愈多，芯片逻辑闸数量也会跟着飞涨，提高整体成本。

视讯辅助处理器支持较佳然部分缺失仍待改良

视讯辅助处理器，以可程序化的方式支持不同视讯标准，即执行译码和编码处理。以视讯辅助处理器设计架构，整体规模通常比以硬件加速器模式要大，例如需要40~50万个逻辑闸，优点是视讯辅助处理器，在支持前述多种类视讯标准时，具有较大应变能力。

视讯辅助处理器通常有2种不同的设计模式，第1种为混合式架构，由专用的CPU(可程序化单元)和附加的影像处理硬件模块，一起构成视讯辅助处理单元，进行视讯加速功能。或是内建多种硬件固定单元，整合大部分影像编/译码单元所通用必备的功能，剩下的部分才以软件进行程序化的动作。这2种设计方式，都是混合式架构，前者支持度灵活但是最佳化效率较差，后者则相反。

第2种方式为支持多标准的专用视讯引擎，这样的的设计方式比混合型效率高，不过专门视讯核心自然没有任何CPU类型的功能，只能进行视讯处理，换句话说，在可程序化的程度略逊一筹。

采用视讯辅助处理器的主要优点，为可支持多标准的编/解碼格式，同一平台亦可支持不同的分辨率和讯框率，且因为可程序化的缘故，不需要太复杂的硬件路线。可升级性也比较好。而视讯辅助处理器整体设计规模中等，通常介于硬件加速和专用处理器间。修复错误能力部份，也可透过软件升级隔离或修正缺陷，不需透过高成本的重新投产模式，才能修正错误。

而视讯辅助处理器的缺点，也正由于专注于影像的处理工作，因此在音效方面也会面临与硬件线路单元相同的状况，需要另外的路线处理。此外，软件编程复杂，例如采用混合模型的系统，包括可能2个不一定是同类型的CPU，为了使2者能协同工作，在整合、数据串流及通讯协议…等都有复杂的程序系统协调问题。

再者，内存专用问题也会发生，由于视讯辅助处理器，需要为程序以及数据设计相对应的暂存内存，但在CPU部分，也需要专属的内存区块，在内存的读取控制会是相当大的问题，例如被视讯辅助处理单元所占据的内存，就无法移作他用，因此在 SoC设计中，内存的容量与配置设计方式，就需要特别注意。
通用处理器优点不少然设计较复杂开发难度高

通用处理器是1种可程序化，能在同1硬件平台上平行支持多种应用的模式。通用处理器的设计方式主要有2种，即DSP核心和RISC核心。但对于RISC核心的解决方案来说，由于缺乏运算功能、内存频宽有限及缺少视讯处理指令，基本上不太适合执行视讯处理或其它复杂数学运算任务。

例如以最常见的通用处理器(ARM/MIPS)来看，就算加入针对多媒体处理的加速指令，全速的H.264译码负担也相当沉重、不流畅，因此这2款处理器也都先后加入DSP处理单元，藉此改善多媒体串流编/译码效能表现。

就整体设计规模来看，通用处理器模式所需逻辑闸数，比前述2种方式多，但通用处理器具有可以任意再使用弹性，例如在平行执行基频处理任务、定位(如GPS)或管理蓝牙连接，对其它任意数据串流进行译码或编码。

因此DSP模式获得绝大多数通用处理器设计模式采用，大部分的编/译码器是运算密集型，而DSP本身便是设计用于高效能数学运算。另外，功耗和成本是行动串流传输中的考虑重点，一般而言，DSP核心也能在进行多媒体编/译码时，提供比通用核心更高的效能及更低的功耗表现。

因此在SoC设计时，便要考虑各种应用层面与效能需求。例如在各种不同的编/译码器，加上不断变革的各种标准要求下，DSP解决方案也必须是可高度程序化的设计，专用的多媒体指令，能大幅加速纯软件多媒体执行速度。透过算法最佳化展现的额外加速能力，有如在视讯处理管线中产生1条快捷方式，不但效率高，且DSP功耗能够降低。

相关指令有用于运动估计和解锁滤波器的绝对差分指令、用于1/2或1/4画素运动补偿的四分平均指令、用于非线性滤波器和预/后处理的分类字节指令与用于DCT、运动重建、1/4画素滤波器、对称滤波器、运动估算和解锁滤波器的字节加/减指令。

通用处理器方案的主要优点包括，支持各种视讯标准，以及各种分辨率和讯框率。加上所有的参数可透过软件定义，举例来说，同一硬件平台可执行讯框率为15fps的QVGA分辨率，也能执行讯框率为30fps的H.264 D1分辨率。在影音讯号同步上，因为DSP能处理不同种类的音讯编码，并能处理音视讯间的同步，所以当同步任务在DSP上进行时，CPU就没有额外负担。

除视讯处理，可程序化的通用处理器，还能执行很多其它工作，并且在支持下一代标准的弹性也比较好，使SoC设计师能轻易支持甚至扩展相关产品发展蓝图。

但通用处理器加速模式当然也有缺点。硅芯片面积大就是许多设计师相当头痛的问题，毕竟可程序化的特性，不可避免地需要较大的芯片面积。而由于能在视讯处理之外，执行多种其它任务，通常会增加一些并不用于视讯处理的功能模块。所幸由于采用通用处理器而增加的面积，有时可透过从系统中去掉CPU来弥补。

而且，目前通用处理器的IP提供厂商相当多，想要选择适合的解决方案，其实要考虑的因素很多，诸如软硬件环境配合、开发套件完整性、IP授权成本以及软件开发的难易度…等，这些也都要比其它方式来得复杂许多。

此外，虽然号称通用处理器，但高阶与低阶通用处理器授权费相差甚大，在设计上，要高阶低用可能超过成本；相对的低阶高用，效能表现可能无法满足设计需求，让导入通用处理器的第1关，就让研发人员伤脑筋。

目前的趋势为，独立的DSP芯片将逐渐被整合于SoC嵌入式DSP所取代，因此针对嵌入式DSP的设计，通常有4种基本设计配置：

1、设计包含1个微控制器和1个DSP(MCU+DSP)。
2、包括1个微控制器和1个DSP，但是DSP同时也控制1个视讯编码/译码硬件模块(MCU+《DSP+VHW》)。
3、使用1个微控制器，DSP和视讯编码/译码硬件模块(MCU+DSP+ VHW)，在该设计中微控制器控制DSP和视讯硬件模块。
4、1个微控制器，1个视讯编码/译码硬件模块，1个音效编码/译码硬件模块(MCU +VHW+AHW)。

了解各种设计模式定位自身产品满足市场需求

可携设备业者，必须确认自己定位的产品功能，再去选择合适的软、硬件编/译码作法，以及编/译码器的支持功能细节，例如最高的视讯分辨率，最大的讯框速率，所支持编/译码规格的等级(Profile/Level)。

对行动多媒体应用，其实3大方案都各有其优缺点，适用的范围也不同，每一方都有其特别突出的能力，但也有其相对弱势之处，采用何种方案，变成产品在设计规划阶段，就必须要精算的一环，设计者研发出符合功耗、性能、功能…等不同要求的产品架构，满足市场在求在更小、更便宜和通用性更强的产品中，包含更多功能和服务需求。

欢迎光临 DIY编程器网 (http://diybcq.com/)