文中描述的方法可针对各种的故障的解决。在故障出现时，只需定位出错的模块，这些模块内嵌一些子模块也无妨；抓信号时将故障模块的输入输出信号抓出即可；利用输入信号重建故障环境，若仿真输出信号和所抓输出信号相同，说明故障环境建立正确；并且在修改代码后可以验证是否修改成功，节省时间，很明确的证明故障真的被解决了，事半功倍。
系统开发在上板调试过程中，有时候出现的bug是很极端的情况或很少出现的情况，而现在通常的做法是：在故障出现的时候通过SignalTap把信号抓出来查找其问题的所在、修改程序；在改完版本后，先要对整个工程进行重新编译，然后再上板跑版本进行验证，看看故障是否解决。有时候故障很难定位，只知道哪个模块出错，很难定位到具体的信号上，给抓信号带来麻烦。故障定位后，修改代码还需要再编译一次产生新版本的下载文件，修改后若还有问题则要重复这一过程，这样从故障定位到修改完成需要很多次编译。上板重新进行验证时，如果这个bug的出现的几率很小，短时间内不再复现，并不能说明在极端情况下的故障真的被解决了。
定位这个故障的时候我们可以很容易知道是哪个模块出了问题，但是具体是其内部的哪个信号还需要下些功夫，如果出错信号隐藏的很深，很难一次就抓到需要的信号；而且即使我们抓到了正确的信号，如果故障在改完之后没有解决，则还需要重新修改、再进行编译，耗费时间；即使改过之后故障不再复现，也有可能是因为bug出现的条件苛刻，无法证明故障真的解决了。虽然定位具体的出错信号很困难，但是定位是哪个模块出错很容易，在bug出现的时候我们可以抓出这个模块的全部输入信号，考虑是否可以利用这些信号在仿真环境下重建bug出现的条件，利用仿真环境具体定位错误信号的位置。定位好错误信号的具体位置后，修改代码，再用相同的条件进行仿真。这样可以通过对修改前后输出数据的对比，很直观的验证修改是否成功，从而在修改成功后只需编译一次即可，节省时间。上板后bug不复现也可以排除是由于极端情况很难满足造成的，去除了后顾之忧，彻底解决了故障。
通过对这个异步FIFO问题的解决，可以证明这种通过所抓信号建立bug存在条件，定位、清除bug的方法是可行的。步骤有将bug出现时SignalTap抓的信号保存成文档文件、利用.dat文件建立bug出现的条件、修改程序后在仿真环境验证修改是否成功。
|
