在实际工作中，经常会遇到这样的情况：在硬件调试中采用SignalTap II反复多次编译并最终捕获到问题的原因时，才会发现，原来这个问题是逻辑问题，是可以在仿真环境下发现并快速解决的。先前没能从仿真中发现这个问题，要么是因为尚未或难以创建对应的测试向量，要么是因为仿真环境下的测试向量与真实环境下的测试条件存在微小的差异。对于设计工程师来说，由于缺乏相应的技术能力、开发时间，甚至是耐心，我们不可能像验证工程师那样对设计进行全面的仿真验证；即使仿真验证很充分，在实际应用中的测试也会发现仿真验证未曾发现的问题。总之，在FPGA设计上板测试后，总会发现或多或少的逻辑bug,，这些bug对应的仿真向量在已有的仿真验证环境中往往都被遗漏了。
那么，有没有一种亡羊补牢的方法可以让我们在硬件调试中发现逻辑bug后，“快速准确”地创建遗漏的测试向量，并且在仿真环境下重现和解决bug呢？由于仿真环境可以给我们提供对RTL设计最佳的可控制性和可观测性，在仿真环境中定位bug，会比通过SignalTap II多次修改信号列表和编译节省许多时间，解bug也就不会那么耗时和痛苦。通过最近一段时间的思考和今天的尝试，我找到了这一方法！
让我们一起来看看这种方法：
1. 在硬件测试中稳定重现bug。
2. 通过代码分析，初步确定bu*生的模块。
3. 通过SignaTap II，捕获产生bug模块的输入输出。
4. 通过分析该模块的输入输出，确认bug在流经该模块后产生。
5. 把SignalTap II中捕获到的所有输入信号波形转化为HDL测试平台中的测试向量。
6. 针对该模块和上一步得到的测试平台运行单元仿真测试，在仿真测试中观察该模块输出，确认bug在仿真环境下重现。
7. 采用该仿真环境查找并定位bu*生的原因。
8. 采用该仿真环境确认对bug的修改是正确和可靠的。
9. 重新编译并测试修改后的FPGA设计。
上述各个步骤，除了5、6之外，都可以与仅采用SignalTap II的硬件调试过程中的步骤对应起来。在步骤5中，快速、准确是这种方法的关键。如果把波形转化为测试向量的过程耗时、易错，那么通过步骤7获得的优势就失去了。
在步骤5中，我采用了SignalTap II的信号波形输出功能，把波形转化为对应的信号取值列表，输出为文本文件；通过文本文件，原本复杂多变的波形文件就可以被其它程序读取并准确地转化为HDL文件，这里我采用的编程语言是Tcl。
采用这一方法，我花费了4个小时完成了Tcl脚本程序，在1个小时的时间内就定位并解决了不久前PV测试出现的一个问题。如果在现有的仿真环境中手工添加该测试向量，可能会花费比写Tcl脚本更少的时间，但是不能保证重现该问题，调试和反复修改测试用例是潜在的工作量；如果在SignalTap II中调试该问题，由于需要多次编译，大概要花费相当的时间，但是Tcl脚本只需要写一遍就可以重用，这一时间成本是可以摊薄到以后的各次调试中去的。
SignalTap II捕获硬件信号波形的原理是基于周期采样，波形中每一个数据样点对应于一个时钟周期。所以，在生成测试向量时，必须产生对应于SignalTap II采样时钟的时钟波形，用来规范测试向量的时序。这里，可以采用VHDL的wait until (clk='1'); 语句，或者Verilog的@(posedge clk); 语句产生相应的定时等待，使每一个采样点对应的激励波形按照采样时钟顺序变化。这一处理，可以在本文所附的示例程序中找到。
附图：
SignalTap II中波形输出为列表的功能
在Modelsim中运行生成测试向量的Tcl脚本
do stp2hdl.tcl是命令，其余的就是从Modelsim命令行传递给tcl脚本的三个参数$1 $2 $3。stp1_auto_signaltap_found.txt对应第一个参数，0和7这两个参数对应stp1_auto_signaltap_found.txt文件中信号列表的索引。替换这些参数，就可以适用于其他的应用环境。
Modelsim中对特定模块生成testbench的工具
Modelsim中采用SignalTap II捕获的测试向量进行RTL级单元仿真的结果