背景大概是这样。复用其他组原来搭建好的FPGA平台，把里面的VPU换成我们现在用的这个版本的VPU，做FPGA protyping。这么做的目的有2个，一个是能够通过FPGA跑大量的case来验证模块的功能，另外一个是可以帮助软件组提前开发驱动，等芯片流片回来后就可以上软件了。
软件组跑一个MPEG4 case，发现跑一个简单的预处理功能是可以通过的，但是要真正解码的时候就会挂住（hang）。boss和模块负责人都感觉是axi id的问题，因为简单的模式用到的id数量简单，可能就是0，所以可以pass，而真正解码的时候会用到比较多的id，如果收发的id不匹配就出错了。
果然，module owner很快就发现一处id不匹配的地方，新版本的vpu需要的id位宽为4，而原来的vpu id位宽为3. 虽然说这个例化不是我做的，但是我觉得如果由module owner检查一下例化可能会避免这样的问题。改过后做了一个FPGA image，现象依旧。。。
debug了很久，没啥进展。boss已经提前布局好了，派我搭建了一套IDENTIFY的dump 波形的环境。但是dump波形也需要module owner来指导，因为只有选准触发条件（trigger），dump出来的波形才会有用。恰好吧，那次算是运气不错，我自己凭感觉选了arready作为触发条件，他们在这个波形里面看出了问题，发现master送出去的id是 "110"，slave回应的id是"010"，正好有一位丢失了。这里要说一下，由于芯片很大，做FPGA protyping的时候被分割成了4个部分，master（vpu）和slave（DDR/fabric）分别处在不同的FPGA中。在slave那块FPGA寻找，果然发现了这边的id 只用了2位，修改过来，发现问题好了不少。但是H.264的case又hang住了。。。
还是怀疑，可能是软件组的问题，因为我们到现在为止已经解决了不少问题了，怎么可能还有问题。在boss的催促下（还是boss思路开阔啊！），继续用IDENTIFY去追波形，这下因为目的很明确了，dump信号比较少，因而dump的时间可以很长，在分析波形之后发现id[1]和id[2]倒置了。根据这个分析，发现是两块FPGA pin-assignment不匹配，正好是这两位给倒置了。
现在呢，问题还在继续，MPEG4和H.264过了，JPEG部分倒是出现了问题，而且encoder部分也有问题。现在的想法是把pin-assignment文件确认比较一遍。
对于这次漫长的debug，简单总结下。
1. 工欲善其事，必先利其器。搭建好IDENTIFY环境对这个debug非常关键。boss觉得要这么做，他的思路是什么，为什么该这样。
2. 第二次发现了同样的问题，就应该把整个通路都trace一遍，而不是根据常规思路想当然的认为该检查的都检查过了，无从下手。
3. FPGA的工作主要还是应该由module owner负责更合适。