"基于Power架构的视频压缩编码算法的IP核验证系统"的实际意义

     上周发现了大小端的问题之后，运动估计IP核计算结果和软件计算结果不同的问题基本解决，但是还有些宏块的计算结果不同，我们测试了foreman序列的0到5帧图像，将不同的结果显示在终端上，见下图：

     可以看到：在执行第1行，第10列的时候，出现了问题，结果不同。仔细的观察之后，我们发现凡是运动矢量的水平分量是7（pe15负责计算）的sad会出问题。我们使用仿真程序进行了仿真，发现计算的结果和IP核的计算结果是相同的，可以说我们的IP核设计的有一部分问题，具体的仿真图如下：

可以看出仿真的结果与IP核的执行结果是一致的，我们看看送入PE15的数据是否正确，下面是仿真的内部结果：

可以看到，PE15得到的SW数据顺序是169，135，193，205，204，179，.....。我们使用VC6得到PE15应该得到的数据是：

169，153，158，144，109，139，202，211，....。见下图：

 

    原因是PE15对应的MUX的控制信号全是零的原因，数据选择错误，我们对MUX的控制信号产生器的VHDL代码进行了修改，再进行仿真，详细的结果如下：

可以看出PE15的SW数据正确了，最终结果也是正确的，见下图：

将修改后的VHDL代码（关于MUX信号产生器）在EDK中更新后，IP核与软件执行的结果完全相同，见下图：

    为什么在修改MUX控制器之前有大部分的宏块的执行结果是完全正确地？因为PE15对应的是运动向量的水平分量为7（出现的几率比较小）的SAD计算任务，大多数运动向量的水平分量都小于7。这个情况我们在开始设计时没有发现，因为我们仿真时用的数据都是位于画面中间的宏块（也就是运动向量一般不大可能太大）。不过这个问题恰恰说明了我们的IP核验证系统的功能，我们可以使用它对大量的数据进行全面的仿真，而不是仅对某些数据进行测试，而且这样做是非常方便的（使用的是软件）。这样可以发现一些潜在的问题。

    现在的运动估计IP核应该没什么问题了。

              苏睿