在实际工作中，经常会遇到这样的情况：在硬件调试中采用SignalTap II反复多次编译并最终捕获到问题的原因时，才会发现，原来这个问题是逻辑问题，是可以在仿真环境下发现并快速解决的。先前没能从仿真中发现这个问题，要 么是因为尚未或难以创建对应的测试向量，要么是因为仿真环境下的测试向量与真实环境下的测试条件存在微小的差异。对于设计工程师来说，由于缺乏相应的技术 能力、开发时间，甚至是耐心，我们不可能像验证工程师那样对设计进行全面的仿真验证；即使仿真验证很充分，在实际应用中的测试也会发现仿真验证未曾发现的 问题。总之，在FPGA设计上板测试后，总会发现或多或少的逻辑bug,，这些bug对应的仿真向量在已有的仿真验证环境中往往都被遗漏了。riple
那么，有没有一种亡羊补牢的方法可以让我们在硬件调试中发现逻辑bug后，“快速准确”地创建遗漏的测试向量，并且在仿真环境下重现和解决bug呢？由于 仿真环境可以给我们提供对RTL设计最佳的可控制性和可观测性，在仿真环境中定位bug，会比通过SignalTap II多次修改信号列表和编译节省许多时间，解bug也就不会那么耗时和痛苦。通过最近一段时间的思考和今天的尝试，我找到了这一方法！riple

让我们一起来看看这种方法：
1. 在硬件测试中稳定重现bug。
2. 通过代码分析，初步确定bug产生的模块。
3.通过SignaTap II，捕获产生bug模块的输入输出。
4. 通过分析该模块的输入输出，确认bug在流经该模块后产生。
5.把SignalTap II中捕获到的所有输入信号波形转化为HDL测试平台中的测试向量。
6. 针对该模块和上一步得到的测试平台运行单元仿真测试，在仿真测试中观察该模块输出，确认bug在仿真环境下重现。
7.采用该仿真环境查找并定位bug产生的原因。
8.采用该仿真环境确认对bug的修改是正确和可靠的。
9. 重新编译并测试修改后的FPGA设计。

上述各个步骤，除了5、6之外，都可以与仅采用SignalTap II的硬件调试过程中的步骤对应起来。在步骤5中，快速、准确是这种方法的关键。如果把波形转化为测试向量的过程耗时、易错，那么通过步骤7获得的优势就 失去了。riple
在步骤5中，我采用了SignalTap II的信号波形输出功能，把波形转化为对应的信号取值列表，输出为文本文件；通过文本文件，原本复杂多变的波形文件就可以被其它程序读取并准确地转化为 HDL文件，这里我采用的编程语言是Tcl。riple
采用这一方法，我花费了4个小时完成了Tcl脚本程序，在1个小时的时间内就定位并解决了不久前PV测试出现的一个问题。如果在现有的仿真环境中手工添加 该测试向量，可能会花费比写Tcl脚本更少的时间，但是不能保证重现该问题，调试和反复修改测试用例是潜在的工作量；如果在SignalTap II中调试该问题，由于需要多次编译，大概要花费相当的时间，但是Tcl脚本只需要写一遍就可以重用，这一时间成本是可以摊薄到以后的各次调试中去的。riple

SignalTap II捕获硬件信号波形的原理是基于周期采样，波形中每一个数据样点对应于一个时钟周期。所以，在生成测试向量时，必须产生对应于SignalTap II采样时钟的时钟波形，用来规范测试向量的时序。这里，可以采用VHDL的wait until (clk='1'); 语句，或者Verilog的@(posedge clk); 语句产生相应的定时等待，使每一个采样点对应的激励波形按照采样时钟顺序变化。这一处理，可以在本文所附的示例程序中找到。


附图：

SignalTap II中波形输出为列表的功能

在Modelsim中运行生成测试向量的Tcl脚本

Modelsim中对特定模块生成testbench的工具

Modelsim中采用SignalTap II捕获的测试向量进行RTL级单元仿真的结果

程序示例：1831963735254.zip

相 关链接：
FPGA设 计开发中应用仿真技术解决故障的方法(图)这篇文章启发我找到了这一调试方法，向原文的两位作者致谢。本篇博客文章提出了原文思路的另外一种实现方法。

Automating the FPGA Design Debug Process:When Full Visibility is Needed
This comprehensive approach cuts greatly into the time it takes to pinpoint the cause of the particularly vexing bugs caused by intermittencies. It takes advantage of FPGAs' speed for most of the debugging effort and transfers the task to a simulator when full, detailed analysis is required. In essence, TotalRecall technology can be thought of as a"fast-forward button" for simulators.