针对H.264的编译码设计以及各种硬件加速架构
——
由H.264具有一系列优于MPEG4和H.263的特性，在相同的重建图像质量下，能比H.263节省约50%左右的流量。但是，在获得优越性能的同时，H.264的计算复杂度却大大增加。
了解视讯编译码发展历史的读者会知道，H.264编码的计算复杂度大约相当于H.263的3倍，解碼复杂度大约相当于H.263的2倍，乍看之下，所得到的成果似乎与计算负担不成比例，考虑到以目前的网络环境、硬件的总线频宽限制等因素，现阶段硬件频宽与网络环境的拓展有其限制且进展缓慢，但是处理器的计算能力一日千里，与其在硬件或网络环境花成本、下功夫，不如利用更强大的处理器及更有效率的编码机制来完成。
装上高效能处理器之后，一般的纯软件解压缩方案在个人计算机平台上，已经可以达到完美的播放质量与速度，但是移动产品受限于功耗问题，处理器的性能必须有所妥协，因此移动产品在进行实时译码的过程中就会显得力不从心，综观市面上可播放H.264视讯的移动产品，以纯软件来完成译码工作，几乎都无法达到完美的流畅度。
△图说：PC的软件译码能力已经完美肩负起BD影片的播放需求。（www.Amazon.com）
视讯编译码导入SoC的关键技术
懂得运用多媒体架构对开发者来说十分重要，应用在视讯编译码的处理架构相当多，针对移动应用方面来说，就可包括了硬件线路单元、独立硬件线路芯片、嵌入式DSP、独立视讯加速处理器、具备多媒体加速指令集的通用处理器等等，在SoC之中，我们常可见到这些架构彼此混用，事实上，适当的混合不同架构的处理单元，常是1款SoC设计成功的关键，过于单向的设计，可能会严重影响到SoC产品的应用广度。
纯粹硬件线路(Hardwired)的视讯编译码设计
老式的硬件加速技术只执行1个特定标准(通常是单个标准)的单一功能(编码或译码)，具有最高的效率和较少的逻辑闸。研发时，不同的SoC只有在功能完全相同时才能复用，例如当加速器支持以VGA分辨率编码的MPEG-4简单格式时，而当加速器需要同时支持MPEG-4(简单格式)和分辨率为D1的H.264(基线格式)编码时，则需要完全重新设计，需要大约35万个逻辑闸。
体积的精省是采用硬件加速器的主要优点，因为固定电路芯片规模可以做到非常小。由于硬件线路只执行固定的操作，不包括任何指令操作(存取、译码)，也没有程序储存器管理。因此逻辑闸数较少。而逻辑闸数目少，晶体管数量也少，每单位的晶体管效率高，因此功耗较小。而在性能方面，由于这是一项效率非常高的解决方案，运作的执行时间和速度都较快。
上述方案优点固然不少，但是也有不少缺点，首先不同功能取向的硬件线路译码芯片，只能解决单一的编译码需求，因此视讯译码芯片只能处理视讯。采用硬件加速器时，多媒体中的音效和语音部分必须由SoC中的其它部分来处理(通常是CPU或DSP)；其次，音效与视讯之间的同步化必须在CPU上来执行。
在CPU上实现同步增加了研发难度、整合难度和QA，如此一来也会带来处理器的计算负载，而硬件线路未必能够负担起全部的运算流程，当采用硬件加速器时，CPU通常执行算法中的讯息编码(如CAVLC)和后处理(如去方块滤波器)，这使得该方案耗费的功率极大(在大约150MHz的载荷上，1个ARM11内核消耗的功率可能就高达120mW以上)。
而硬件线路最大的缺点，在于无法进行软件升级和缺陷修复。要修正错误，通常也要伴随着芯片本身的改版以及重新投片生产，已经生产出来的缺陷产品无法进行任何修补工作。针对新一代的产品，在SoC中执行特定任务的硬件加速器似乎不能满足下一代的需求，也就是功能没有拓展性，无法程序化，效率也固定，无法通过软件来进一步最佳化。
至于专属内存方面，在SoC中，硬件线路芯片的专用内存不易被其它组件存取，因此从成本和硅芯片面积的角度上来看，效率显得较低。 虽然某些硬件线路加速器能够支持多种标准(如H.264 Baseline格式和MPEG-4 Simple Profile)的译码运算，但尽管这些硬件线路设计加速器弹性佳，且兼具能性能表现，却也同时牺牲了逻辑闸和晶体管数目少的最大优点。
硬件线路设计案例
△图说：由交通大学与联发科合作开发的硬件线路H.264译码的芯片。（交通大学）
交通大学与联发科在2006年合作开发出针对H.264译码的低耗电系统单芯片，便是针对移动应用所开发出来的1款产品，由于是采用硬件线路独立芯片，相当适用于各类型的移动影音装置，芯片本身采用108pin CQFP封装，内嵌了22.75Kb的高速缓存，并外接2颗4MB的SDRAM。核心电压为1.8V，而I/O电压则是3.3V，以1P6M CMOS工艺制作，Die size仅有3.9mm x 3.9mm，全速工作时功耗为12.4mW(16.6MHz的速度，D1分辨率，以30fps译码H.264影片)，完全将硬件线路译码的优点发挥的淋漓尽致。
由于这颗芯片采用的是MPEG-2与H.264混合设计，在主要译码核心中，同时内建了MPEG-2与H.264语法器，至于在其它如管线及内存部份则是采共享设计，因此如果想要扩充规模支持其它编码标准，也是有可能的，在架构上具备了相当程度的弹性，或可称为可调性。在设计上有几个重点，那就是H.264与MPEG-2的区块取样定义不同，因此采用了不同阶段并用的区块取样策略。
其次，为了降低耗电，设计人员也大幅减少内存耗电的电路构成及处理步骤。通过将译码处理所需要的内存空间区分为3个等级，分别准备各自最佳的内存容量。3个等级的内存区块分别称为「Macroblock Memory」、「Slice Memory」及「Frame Memory」。 Macroblock Memory主要用于储存进行Motion compensation等的单位区块的像素数据。Slice Memory主要用于储存Macroblock附近的影像数据。Frame Memory用于保存现有Frame和参考Frame，这部份采用了2个4MB的SDRAM，以及与芯片外部连接的总线。
辅助处理器
辅助处理器以可程序化的方式支持不同的视讯标准，通常执行译码和编码处理。基于视讯辅助功能的处理器架构规模，通常比基于硬件加速功能的处理器，芯片面积较大(40~50万个逻辑闸用于视讯辅助处理器，视不同IC厂商的设计而有不同)，但是，视讯辅助处理器在支持多视讯标准时有较大的应变能力。除了仅针对视讯应用的加速以外，以DSP为基本架构的多媒体加速方式也是主流之一，许多公司在DSP架构方面也下了不少的功夫。
△图说：TI的OMAP产品便是结合了通用处理器、DSP与特定多媒体加速单元的设计典范。（www.TI.com）
■混合模型：由专用的CPU和附加的IP模块一起构成视讯辅助处理器，实现视讯加速功能。此类架构以ARC公司的视讯处理子系统较为优秀。以其最新的Vraptor架构为例，该架构采用了特殊多核心方案，其中有多个高性能处理器被连接到多个SIMD处理器和多个DMA引擎，还采用了针对不同应用领域的加速器，这些相互连结的设计，均采用了低耗电、低延迟的通讯信道和Local宽带数据总线。
ARC公司的多媒体加速子系统可与包含ARM或MIPS等不同的嵌入式处理器进行连结，并设计于单一SoC上，但这并不是基于效能考虑，而是基于软件开发的习惯与旧有软件的兼容性，基本上，该子系统原本就包含了1个ARC700的可配置处理器，在性能表现上并不逊于其它嵌入式应用处理器。
△图说：ARC的VRaptor体系在多媒体应用方面的效能极佳，且兼具弹性。（www.ARC.com）
VRaptor架构利用以128位数据向量执行的单一指令多数据流(SIMD)媒体处理器，来扩展ARC700 CPU运算功能，利用1个专用的向量缓存器文件，可分别以4个32位单元、8个16位单元或16个8位单元来进行配置，弹性相当高。SIMD处理器通常采用与 ARC700 CPU相同的频率频率，并具有两种工作方式：一种是只简单地扩展ARC700 CPU系列管线的紧密结合方式；另一种为松散耦合方式。在松散耦合方式中，SIMD处理器与ARC700 CPU架构平行，彼此有独立的内存和处理单元结构，不会因为特定内存或处理单元被占用而影响到整体效能。
VRaptor架构包含了2种多媒体处理子系统，其一是针对多标准视讯的译码方案，另外1种则是针对音效应用，该架构除了可专心扮演子系统的角色，进行特殊多媒体加速处理以外，也能摇身一变成为主角，进行一般通用运算，算是该架构的最大特点之一。
■专用视讯核心：1种多标准视讯引擎，此方案较混合模型架构的执行效率为高，不过视讯核心可能仅具备简单通用运算能力，或根本没有任何CPU的功能，因而只能进行视讯处理。
采用视讯辅助处理器的主要优点为：
1. 支持多标准－支持多种视讯编译码格式而无需硬件扩展。
2. 可升级性－同一平台可支持不同的分辨率和讯框率。
3. 规模－该方案的规模通常介于硬件加速和专用处理器之间。
4. 缺陷修复－与硬件线路芯片不同，该方案可透过软件升级来隔离缺陷(不需要重新投片)。
通用处理器(RISC/DSP架构)
若以寻常的通用处理器(ARM/MIPS)来看，即便加入了针对多媒体处理的加速指令，其实也难肩负起全速的H.264 BaseLine Profile译码，因此这两款处理器也都先后加入了DSP处理单元，以改善多媒体串流编译码的效能表现。虽然这些DSP单元在效能方面仍要稍逊于TI或其它公司的DSP单元，不过其优点在于整合性高，不需要另外支付授权费用，软件开发也可以一脉相承，这是其最大优势。
△图说：此类独立的DSP芯片将逐渐被整合于SoC的嵌入式DSP所取代。（www.TI.com）
由于DSP逐渐成为未来串流媒体编译码加速的主角之一，在SoC设计时，便要考虑到各种应用层面与效能需求。首先，在各种不同的编译码器和不断变革的标准要求下，解决方案必须是可程序化的；其次，大部分的编译码器是运算密集型，而DSP本身便是设计用于高效能数学运算。另外，功耗和成本是移动串流传输中的重要考虑，一般而言，DSP核心也能在进行多媒体编译码时，提供比通用核心更高的效能以及更低的功耗表现。
典型的音效/视讯串流多媒体系统，通常同时使用内部存储器和外部内存。内部存储器是以DSP核心频率速度运行的快速内存；外部内存比较慢，但价格也较便宜。编译码指令储存于外部内存，但下载到内部存储器中执行。由于视讯串流数据量庞大，除非必须，通常置于芯片之外，而音效串流数据则可视芯片需求内外任意放置，还可以根据需要，将一些IP模块安置在SoC系统总线上。
目前的趋势是每2年就会发布新的编解碼标准，每个新标准会需要更多的DSP周期。因此，选择可依兼容性发展蓝图来演变的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和视讯硬件模块；最后1种，设计包含1个微控制器，1个视讯编码/译码硬件模块，1个音效编码/译码硬件模块(MCU +VHW+AHW)。
1.MCU+DSP：微控制器和DSP用于低视讯分辨率(CIF)，软件可升级，支持多种音、视讯标准的系统。DSP用于音效译码，视讯译码和音/视讯同步。虽然性能有限，但系统非常灵活，此平台可轻松实现多种音效和视讯译码格式支持。
2.MCU+[DSP+VHW]：该视讯硬件模块用于高分辨率视讯编/译码。DSP管理音效编/译码，也负责音/视讯同步，同时也能用于子母画面或其它视讯迭加功能。该系统的1个优势是音效/视讯子系统可设计为1个标准的多媒体编/译码器，可轻松植入系统而不会增加太多的复杂性。DSP是系统多媒体部分的控制器，由于多媒体编/译码系统与微控制系统的连接很松散，因此能够被轻松整合进众多现有微控制器系统中，从而使这个方案具备相当吸引力。该编译码系统可被当作1个具有标准Local总线端子的ASSP产品。
3.MCU+DSP+VHW：在该配置中，DSP用于音效编/译码，而微控制器用于实现音/视讯同步。这需要更复杂的微控制器设计，但可采用与MCU+[DSP+VHW]系统相比之功耗、成本都更低的DSP。由于微控制器必须协调DSP和VHW，同时还要执行其它的控制任务以及所有的协调操作，因此该方案在设计实现上困难很多。
该配置的1个变种方案，是由DSP执行视讯译码、音效编/译码，而视讯编码仍然由硬件执行，这需要1个性能强大的DSP，但会使系统灵活性更强，并支持多种视讯译码标准。
4.MCU+VHW+AHW：在此配置中，微控制器执行除音效、视讯编/译码外的所有任务，音/视讯同步也由微控制器执行。该解决方案除音效子系统灵活性较差(仅能执行原始设计中的音效编译码器而不能软件升级)外，和MC+DSP+VHW很相似。其好处在于它能与特定应用配合，与各种前述方案相比具有最佳的功耗表现。
在上述各类设计中，微控制器负责典型的嵌入式控制任务：包括用户控制连接(如游戏杆、按键控制)，USB/UART/以太网络驱动和协议层 (如TCP/IP, HTTP)等。
linux操作系统文章专题:linux操作系统详解（linux不再难懂）
评论