CAVLC测试

        第一种方法，将设计植入FPGA，FPGA被置于一块验证板上，其输入是由码流发生仪产生的H.264码流，通过FPGA里面的处理，将输出显示于可视设备上从而观察解码的正确性。这种方法的优点在于其与硬件有着极大的关联性，由于设计本身已经被植入硬件，因此可以在很大程度上说明硬件上的一些现象，并且输出的图像给测试者很直观的感觉；同时，本方法也有很多缺点，首先，对于以ASIC为最终目标的设计来说，在FPGA上的验证并不能够说明问题，因为ASIC对时序的要求会更加的严格，其次，本文中只给出了parsing过程的设计与实现，在其它模块缺失的情况下，系统是不可能进行完全的解码的，也就是说，这种验证受到所有模块的制约，只有在所有模块都实现的基础上，才能开始对所有模块进行验证，最后，也是最大的一个缺点，就是这种平台的搭建根本不适合于调试，在含有数百个语法元素的parsing解析过程中，任何一个语法元素的解析出现了错误，后面的所有解析都会完全错误，但是在上述的平台下，我们所能看到的，只是最后的显示结果不对，但是到底问题出在什么地方？到底是什么问题？我们并不知道。于是我们采用了相对简便的第二种方法，用程序读入测试向量(而非用码流仪产生)，然后用仿真工具进行功能和时序仿真，仿真仅仅对parsing过程进行，然后对输出结果进行证。

        在图4-1中，原始的YUV文件先被JM的编码器编码为标准的264压缩流，然后再被解码器解码成可显示的YUV，同时，考虑到参考的完整性，解码器会将parsing过程的输出写入一个Trace file内，这个文件正是我们所需要的，只要将压缩流流过我们的设计，然后将输出同Trace file做比较，就可以知道我们的设计是否正确。在前面说过，为了增加覆盖率，我们需要不只一个码流，实际上，由于H.264的复杂性，我们可能需要很多不同类型的码流才能达到完全覆盖，而产生这些许多不同类型的码流，我们可以利用JM提供的功能改变其编码的方式。在JM的编码器中，会调用一个名为encode.cfg的配置文件作为其编码的参数，将配置文件内的数据读入作为一些指标，而encode.cfg里的各行则是这些指标的具体化，比如说，我们可以通过改变ProfileIDC来改变其编码的级别，可以选择baseline，也可以选择main或extended。