运动估计IP核在ML403中执行的结果不一样,经过一个星期的调试,问题初步得到解决。
2006-10-26 12:23
507 查看
将自己编写的运动估计IP核通过PLB总线与 ML403的ppc405相连,但是结果不正确。从下图可以看出:
我们使用的序列是标准测试序列foreman.qcif的第1帧做当前帧,第0帧做参考帧,对于宏块左上角位置(16,16)的宏块,使用纯软件的结果是0x7d0267,即mv=(5, -1),sad=0x267;使用硬件IP得到的结果是0xa80285,即mv=(0, 2),sad=0x285;我们设计的ME核的结果见文献:
Yang, K.-M., Sun, M.-T., Wu L, “A family of VLSI designs for the motion compensation block-matching algorithm,” IEEE Trans. Circuits and Systems for Video Technology, vol. 36, no. 10, pp.1317-1325, Oct. 1989.
我们使用VHDL语言将它实现,在ISE中使用ModelSim做了后仿结果是正确的,仿真图见:
可以看到它的结果是正确的:0x7d0267。
那么我们错在那里了?
1、怀疑是执行时钟的问题,是不是太快了(100Mhz),于是开始降频到50Mhz和25Mhz,问题依旧。
2、怀疑是PLB总线的问题,于是将它移植的OPB接口,问题依旧。
3、怀疑是逻辑资源占的太多了(整个设计占了XC4VFX12的93%),place或route时处理问题(因为某些PE单元的工作时正常的,从运算结果可以看出),于是使用ML402进行试验,将同样的IP核挂载到Microblaze的OPB总线上,结果依旧。
4、没辙了,唯一的救命稻草是Chipscope pro了,经过一天的学习,我们开始捕获一个PE单元的内部信号(这里是PE8),具体的结果见下图
其中的b信号是当前宏块的象素值:可以看出它的输出顺序是127,140,142,133,208,166,121,119,...
但是我们取出这块数据,我们希望的数据顺序是133,142,140,127,119,121,166,208,....
所以这是因为PPC405是大端工作模式,而我们的ME IP采用的是小端工作模式所致。于是在数据输入的时候先转换为小端模式,问题解决了,大端到小端的程序如下:
small_endian_value = *(pointer1);
byte0 = small_endian_value & 0xff;
byte1 = (small_endian_value & 0xff00)>>8;
byte2 = (small_endian_value & 0xff0000)>>16;
byte3 = (small_endian_value & 0xff000000)>>24;
big_endian_value = (byte0 << 24) + (byte1 << 16) + (byte2 << 8) + (byte3);
正确的结果如下:
相应使用chipscop pro捕获的数据是:
同样的大端小端问题还出现在视频输入IP中,这个问题正在调试。
我们使用的序列是标准测试序列foreman.qcif的第1帧做当前帧,第0帧做参考帧,对于宏块左上角位置(16,16)的宏块,使用纯软件的结果是0x7d0267,即mv=(5, -1),sad=0x267;使用硬件IP得到的结果是0xa80285,即mv=(0, 2),sad=0x285;我们设计的ME核的结果见文献:
Yang, K.-M., Sun, M.-T., Wu L, “A family of VLSI designs for the motion compensation block-matching algorithm,” IEEE Trans. Circuits and Systems for Video Technology, vol. 36, no. 10, pp.1317-1325, Oct. 1989.
我们使用VHDL语言将它实现,在ISE中使用ModelSim做了后仿结果是正确的,仿真图见:
可以看到它的结果是正确的:0x7d0267。
那么我们错在那里了?
1、怀疑是执行时钟的问题,是不是太快了(100Mhz),于是开始降频到50Mhz和25Mhz,问题依旧。
2、怀疑是PLB总线的问题,于是将它移植的OPB接口,问题依旧。
3、怀疑是逻辑资源占的太多了(整个设计占了XC4VFX12的93%),place或route时处理问题(因为某些PE单元的工作时正常的,从运算结果可以看出),于是使用ML402进行试验,将同样的IP核挂载到Microblaze的OPB总线上,结果依旧。
4、没辙了,唯一的救命稻草是Chipscope pro了,经过一天的学习,我们开始捕获一个PE单元的内部信号(这里是PE8),具体的结果见下图
其中的b信号是当前宏块的象素值:可以看出它的输出顺序是127,140,142,133,208,166,121,119,...
但是我们取出这块数据,我们希望的数据顺序是133,142,140,127,119,121,166,208,....
所以这是因为PPC405是大端工作模式,而我们的ME IP采用的是小端工作模式所致。于是在数据输入的时候先转换为小端模式,问题解决了,大端到小端的程序如下:
small_endian_value = *(pointer1);
byte0 = small_endian_value & 0xff;
byte1 = (small_endian_value & 0xff00)>>8;
byte2 = (small_endian_value & 0xff0000)>>16;
byte3 = (small_endian_value & 0xff000000)>>24;
big_endian_value = (byte0 << 24) + (byte1 << 16) + (byte2 << 8) + (byte3);
正确的结果如下:
相应使用chipscop pro捕获的数据是:
同样的大端小端问题还出现在视频输入IP中,这个问题正在调试。
相关文章推荐
- crontab执行sh脚本和手动执行结果不一样问题解决
- java调试打断点和不打断点执行结果不一致问题解决
- 关于VS2010调试时出现的找不到可执行文件问题的可能的解决办法
- java执行cmd命令,返回结果中文乱码问题解决
- shell执行和crontab执行结果不一样的问题
- 对常规启用 IIS6.0 Gzip 方法的补充,用于解决wget、curl等无法得到压缩结果的问题
- VS2010调试“正试图在 OS 加载程序锁内执行托管代码”和运行出现R6034问题解决
- 调试PCB板中,结果短路了,这是一个非常纠结的问题,写下解决经验
- OD提示 "为了执行系统不支持的动作, OllyICE 在这个被调试的程序中注入了一点代码, 但是经过5秒仍未收到响应..." 解决办法
- Rsa 非对称加密算法使用问题分享--使用通过密钥对同一段数据加密得到结果每次不一样
- java执行cmd命令,返回结果中文乱码问题解决
- keil中调试时执行到prinitf停住不继续进行问题解决
- iOS调试——解决playground无法执行的问题
- asp.net Global.asax中Session_End不能执行问题最终解释与调试结果
- 解决Ajax在兼容模式下后台调用执行两次结果不变的问题(已解决)!
- 关于VS调试时出现的找不到可执行文件问题的可能的解决办法
- OD提示 "为了执行系统不支持的动作, OllyICE 在这个被调试的程序中注入了一点代码, 但是经过5秒仍未收到响应..." 解决办法
- 解决问题:vs 使用命令行参数调试时出现"当前项目设置指定将使用特定的安全权限对该项目进行调试.在此模式下,命令行参数将不会传递给可执行文件."
- C# 启动调试 开始执行(不调试)多线程程序执行效果不一样 Mutex(已解决)
- IAR_cc2530调试mpu6k结果不准确问题的解决方法。