在集成测试阶段，发现的许多bug并不是硬件本身的，其实是软件的配置错误。要么是地址有误，要么是取值错误，再就是配置的先后顺序和时机有误。

确认和定位这类问题的方法有四种：

1. 检查调试程序向串口输出的打印信息。

2. 通过和已知正确的简单脚本程序进行结果比较，如果简单脚本好使，那么就是软件的配置问题。

3. 通过把简单脚本中的所有配置写入操作替换为读出操作来检查软件已经配置好的信息。可以把读出的信息与简单脚本进行逐行比较，如果检查出差异，就可以很容易 地判断出错误所在。其实，这一方法就是软件工程师手工检查配置正确与否的方法。如果加上自动执行和报告功能，也可以用于比较复杂和冗长的脚本。

4. 用SignalTap II抓取CPU总线操作波形，针对特定地址和数据设置触发条件。

进入集成测试，大批量的打印信息无疑会减缓程序运行速度，如果碰上时间相关的问题，很有可能问题不会重现；通过第二种方法可以推断出软件有错误，但 是很难精确定位；由于CPU运行速度较慢，而Signal Tap II的存储深度有限，很难抓取到多次总线操作（可以采用分段存储方式）。

如果需要在CPU总线上捕获大批量的操作事件，可以考虑采用In-system Memory Content Editor，或者采用Virtual JTAG配合一个FIFO实现。一次总线操作只对应一个存储单位，可以实时捕获大量的总线操作信息。

如果采用了Virtual JTAG，一个额外的好处是，可以动态输入对特定地址进行过滤的掩码。通过地址过滤，只抓取针对特定地址进行的总线操作。这样做有些类似于动态设置 SignalTap II的触发条件，增强了这一方法的灵活性。

加入掩码操作是很必要的，在最近一次的测试中，就发现软件的无关写入操作（主要是页面切换操作）很多，导致用于捕获trace的存储器在很短的时间 内被充满。不加入掩码，就无法有针对性地进行捕获。

后记：这里提出的采用Virtual JTAG动态地捕获CPU-FPGA总线读写事务的方法已经实现了，相应的文章发表在2009年12月15日出版的EDN杂志上：Debug a microcontroller-to-FPGA interface from the FPGA side。

相关链接：Quartus II中添加Tk程序的几个关键语句

其实，很多时候，按照方法3进行手工操作更直接、更有效。