熵的定义H=【Ｈ．２６４熵解码器ＣＡＶＬＣ的硬件设计】

　　 　　H.264/AVC是ITU-T和MPEG组织共同推出的最新一代视频压缩标准，其压缩效率较H.263和MPEG-4simple profile有显著提高。在相同的重建图像质量下，H.264比H.263节约50％左右的码率。因其更高的压缩比、更好的IP和无线网络信道的适应性，在数字视频通信和存储领域得到越来越广泛的应用。
　　在编码方面，H.264/AVC所采用的基于上下文自适应的可变长编码(CAVLC)是变长编码的一种扩展，它根据编码语法元素动态调整编码中使用的码表，以达到好的编码效率。
　　H.264解码器的实现一般有效的方法是采用软硬件协同设计的方法。合理地进行软硬件划分，有着更低的成本和更快的解码速度。H.264代码中熵解码部分占了较大一部分的计算量，而其功能比较单一同时控制方式也相对简单，适合于硬件实现。
　　
　　H.264中CAVLC解码原理及流程
　　
　　在H.264中，因为经过量化后的块中的非零变换系数分布比较稀疏，在CAVLC中采用了将每个非零变换系数的数量、大小和变换系数的位置分别编码的方法；同时，每个块的高频部分的系数较小且出现1的概率很大，所以对于这些拖位系数1的数量和符号进行了专门编码。
　　在CAVLC中，H.264采用若干VLC码表，不同的码表对应不同的概率模型。编码器能够根据上下文，如周围块的非零系数或系数的绝对值大小，在这些码表中自动地选择，最大可能地与当前数据的概率模型匹配，从而实现了上下文自适应的功能。上下文模型的选择主要体现在两个方面：编码非零系数个数和拖尾系数的个数所需要表格的选择以及除拖尾系数外非零系数的幅值后缀长度的更新。
　　CAVLC共有6个语法元素需要解码，包括非零系数个数、拖尾系数的个数、每个拖尾系数的符号、除拖尾系数外非零系数的幅值、最后一个非零系数前零的个数和每个非零系数前零的个数。
　　CAVLC的解码过程如下：初始化工作，确定输入数据的块类型等参数；求变量NC，根据NC的值选择所要查的表格；查表得出语法元素非零系数个数和拖尾系数的个数；根据拖尾系数的个数解出拖尾系数的符号；解码除拖尾系数外非零系数的幅值；根据非零系数个数查表求出最后一个非零系数前零的个数；解码每个非零系数前零的个数。
　　
　　CAVLC解码器的硬件设计
　　
　　1 设计方案以及性能目标
　　本设计方案的主要思路是将CAVLC解码各个句法元素的解码设计成单独的功能模块，每个模块的功能相对都比较简单，由一个总体控制单元，负责调度功能块之间的流水线处理以及数据的调度。
　　为了达到目标的性能要求，本设计对于句法元素的解码过程进行了优化处理，并且将其中数据的调度过程隐藏在功能模块之间的流水处理中。这样的设计基本上将解码所浪费在数据调度上的时间冗余降到了最低，大大提高了解码的速度。
　　本文中所论述的CAVLC熵解码器将应用于H.264视频解码ASIC芯片的设计中，所采用的器件为VIRTEX2XC2V6000。设计指标为1920×1088@30f/s@200MHz，达到H.264主框架第4层的解码速度要求，向下兼容支持基本框架协议，不支持H.264协议的MBAFF特性。该产品的目标应用定位是高清电视机顶盒、IPTV、高清碟机(blue-ray/HD DVD)以及手持式移动多媒体终端处理器的解码模块。
　　
　　2 硬件模块设计
　　CAVLC硬件解码器总体结构所示，主要由5个功能模块(Coeff_tokenDecOder、TotalZerO DecOder、Run_before Decoder、TrailingOnesDecoder和Level Decoder)和一个总体控制模块(CAVLC Contraller)组成，另外包括了一个内部的SRAM模块(即图1中的memory)，用于存储block信息。
　　五个句法元素的Decoder分别执行对于相应的句法元素的解码工作，总体控制模块执行协调各模块工作，对SRAM数据的存取，向外申请接受码流数据，以及将各子功能模块解码得到的数据重组和向外输出传递的功能。下面就对各个模块进行说明，Coeff_token Decoder和Level Decoder是其中较为复杂的功能模块，结合了电路设计图进行介绍说明。
　　Coeff－token Decoder用于解码非零系数个数和拖尾系数个数，包括了5张表(4张定长码表和l张定长码表)。码表中有的码字很短，只有1～3位，有的码字较长，因此需要按照表的特点来设计电路。主要的电路设计如图2所示。句法元素Coeff－token的主要过程为查表的过程，有五张表需要查，所以针对每张表设计一个LUT查表电路，每个LUT电路设计成一个可以调用的子模块。需要根据左边和上面的非零系数的个数计算出的当前NC值，从而确定调用五张表格中的哪张来进行查表。所以在查表电路前加上一个MUX选择电路，对于表格进行选择。由于按照了表的特点来设计电路。将码字进行分类，加快查表电路的速度。这样的划分方式加快了硬件查表的搜索，减少的查表时间，使得查表过程在一个时钟周期内即可完成。
　　TrailingOnes Decoder用于解码拖尾系数，由于之前的Coeff―tokenDecoder中解出的仅仅是拖尾系数的个数，所以这个模块真正解码的是拖尾系数的符号，并将拖尾系数加上符号输出给控制模块。拖尾系数最多只可能有三个，所以可以利用这一特点来优化拖尾系数解码电路的设计。为了减少解码所需要的时钟，这部分采用了并行检查的方式，只需要一个时钟周期就可以解码得出全部的拖尾系数。TotalZero Decoder用于解码最后一个非零系数前零的个数，包括了两张表格，一张为常用表，另外一张为ChromaD C的专用表格。可以按照Coeff－token Decoder电路的做法，按照表的特点来设计电路。
　　非零系数的解码是功能模块中比较复杂的部分，因为其中有上下文模型的更新部分。主要包括了前缀的解码、后缀的解码、符号的解码和前缀程度根据上下文自适应更新这几部分。Level由两部分组成，前缀(1evel prefix)和后缀(1evel suffix)。Level的解码过程为先初始化中间变量suffixLength的值，由于已经解出了非零系数的个数TotaiCoeff和拖尾系数的个数TrailingOnes，所以可知有TotalCoeff-TrailingOnes个 level的解码循环过程需要进行。在每次解码level的循环中，先计算levelCode，然后根据levelcode的奇偶性计算出level的值，最后根据解出的level的绝对值是否大干相应的阈值来更新suffixLength的值。
　　在硬件实现中将解码一个level的工作分两步完成，第一步是计算level的值，然后更新suffixLength的值。为了降低level解码的复杂性，使得其解码过程能在一个周期内完成，对于前缀的解码进行了一定的优化设计，使用典型的快速搜索第一个1的电路来完成。主要的电路设计。先通过InitREG电路对于一些寄存器进行初始化工作，然后开始解码，查表电路LUT得出了前缀，然后将去除前缀的码流通过一个MUX选择得出CODE―LEVEL(LEVEL值)和CODE_SIGN(LEVEL符号)，前缀和CODE_LEVEL通过一个加法器运算得出了无符号的LEVEL，最后和LEVEL的符号一起进行添加符号的运算输出得出LEVEL，同时运用查表电路来更新SUFFIX LENGTH的值。
　　Run_before Decoder用于解码每个非零系数前零的个数(RunBefore)。在解码Run的时候，要根据zeroleft的值进行查表运算，本设计采用计算的方法，而不是查表的方法来解码Run，以减少这些表所占用的资源。除此之外，从Run_before解码所用的查表表格可以看出，Run大多数情况下所解出的个数是在0～5的范围内，而当其在7～14的范围内时，就代表了level的个数是比较少的。所以可以根据这一特性优化电路，达到每解码一个Run花费一个周期。
　　片内SRAM的设计用于存储block的信息。在每个block解码后都要把这个block的TotalCoeff参数(即所谓的Nc)存储起来用来在解码下个block的时候做预测。因此在设计中加入了8个寄存器，分别用来存储一个宏块中block上面和左边的block的NC值(即NA和NB)。每次解码一个block结束前都会从SRAM中更新好NA和NB的值，为下一个block的解码做好准备。
　　CAVLC的总体控制模块协调控制了各个解码语法元素的子功能模块的顺序解码工作，并在最后将解码后的数据进行重新排列组织输出。主要是由状态机的设计来完成模块间的调度任务。
　　
　　3 设计方案分析
　　在整个电路的设计过程中，要注意如何根据硬件设计的思想来优化软件模型，从而使移植到硬件模块中实现更加节省面积和计算的复杂度。本设计方案中已经对计算比较复杂的LevelDecoder模块的软件模型进行了修改，但对于其他模块还没有进行比较好的设计改进。
　　本设计方案的优点是解码速度很高，达到了高清解码的要求，但为了达到高清解码速度，使用了较多的门数，因此用于小分辨率码流的解码时，就浪费了过多的门数。
　　
　　硬件验证和综合结果分析
　　
　　本CAVLC解码器的硬件设计已经实现并且仿真测试通过。
　　测试平台主要通过从H.264的软件模型中提取相应的码流数据作为硬件模块的输入，将硬件解码得出的残差数据与软件跑出的正确结果进行比对，以测试解码的结果是否正确。通过仿真测试后进行了DESIGN COMPILER的综合，得出的结果能够满足目标的时序要求，门数人概在2万门左右。
　　本设计中解码各语法元素所需要的时间为：Coeff_token Decoder用一个时钟周期，TotalZero Decoder用一个时钟周期，Run_before Decoder每个Run解码用一个时钟周期，TraillongOnesDecoder用一个时钟周期，LevelDecoder用两个时钟周期。
　　从理论上计算一个宏块解码所需要的最长的时钟周期，假设最复杂的情况下，有15个level需要解码，16个Run需要解码，0个拖尾系数，15个非零系数，则可以计算得到一个block所需要的时钟周期为15×2+16+1=47；一个宏块则需要47×16=752个时钟周期。而实际对于所以测试码流得到的结果表明：对于压缩率非常高编码很复杂的码流，平均一个宏块解码所需要的最长的时钟周期为约800个时钟周期，与理论上估计的最差情况相比略多一些用于解码流程的控制冗余；而对于大多数的码流，解码不太复杂，大多测试下来平均用300～500个周期就可以完成一个宏块的解码。
　　对于解码高清电视ASIC芯片的要求，如果最高目标解码分辨率为1920×1088@30f/s，芯片的时钟频率为200MHz。达就要求每个宏块的解码时钟周期如下。
　　因为硬件的整个设计中可以安排各硬件模块宏块间的流水处理，所以我们这样的熵解码CAVLC硬件设计完全可以满足要求。所以本设计非常适合于集成到整个H.264解码器系统中去。