本文针对FPGA实际开发过程中，出现故障后定位困难、反复修改代码编译时间过长、上板后故障解决无法确认的问题，提出了一种采用仿真的方法来定位、解决故障并验证故障解决方案。可以大大的节约开发时间，提高开发效率。

FPGA近年来在越来越多的领域中应用，很多大通信系统(如通信基站等)都用其做核心数据的处理。但是过长的编译时间，在研发过程中使得解决故障的环节非常令人头痛。本文介绍的就是一种用仿真方法解决故障从而减少研发过程中的编译次数，最终达到准确定位故障、缩短解决故障时间的目的。文例所用到的软件开发平台为Altera公司的Quartus II，仿真工具为ModelSim。

问题的提出

系统开发在上板调试过程中，有时候出现的bug是很极端的情况或很少出现的情况，而现在通常的做法是：在故障出现的时候通过SignalTap 把信号抓出来查找其问题的所在、修改程序;在改完版本后，先要对整个工程进行重新编译，然后再上板跑版本进行验证，看看故障是否解决。

这样就会出现三个问题：

①有时候故障很难定位，只知道哪个模块出错，很难定位到具体的信号上，给抓信号带来麻烦。如果故障定位不准确，漏抓了关键信号，则需要重新在 SignalTap里添加信号、编译版本并再次上板定位故障，浪费时间。

②故障定位后，修改代码还需要再编译一次产生新版本的下载文件，修改后若还有问题则要重复这一过程，这样从故障定位到修改完成需要很多次编译。

③上板重新进行验证时，如果这个bug的出现的几率很小，短时间内不再复现，并不能说明在极端情况下的故障真的被解决了。

仿真解决故障的方法

通过对这个异步FIFO问题的解决，可以证明这种通过所抓信号建立bug存在条件，定位、清除bug的方法是可行的。步骤如下：

①将bug出现时SignalTap抓的信号保存成文档文件

Quartus II 平台用SignalTap抓到信号的界面如图2所示。

图1 SignalTap抓信号界面

在信号名称上单击右键，选择图2所示Create SignalTap II List File选项，生成如图3格式界面。

图2 SignalTap II List File界面

图2中界面上半部分显示的是list对信号个数及信号名的描述，下半部分是采样点所对应的信号值，带h的表示是十六进制数值。

将list file另存为文本格式文件即可，如图3所示。

图3 “另存为”选项界面

此后可以把这个文本文件中无用的描述删掉，只留SignalTap抓出来的数据(空格、h等符号也要删掉)，另存为.dat文件供仿真使用。

有了故障出现时的输入数据，我们就可以在仿真环境下构建故障出现的条件。

②利用.dat文件建立bug出现的条件

用verilog语言编写仿真文件(testbench)，使用语句$readmemh或$readmemb将.dat文件中的数据存储到一个设定的ram中，如：$readmemh(“s.dat”,ram)。

注意$readmemh读取是按照十六进制数据进行(认为.dat文件中的数据都是十六进制数)，会自动将其转换为4位二进制数存入ram中，所以设定的ram位宽要是.dat文件中数据位宽的4倍；使用$readmemb时，存储SignalTap所抓信号时，信号都要先设定为binary类型，ram位宽就是.dat文件数据的位宽。ram的深度为.dat文件中数据的个数。

然后在程序里把ram中数据按照所对应时钟沿输出到一个寄存器变量中，ram地址累加即可。

复现bug存在条件时，需将模块的输入信号与ram中的数据位相对应，仿真文件调用模块时，将寄存器data对应位作为输入接入即可。

③修改程序后在仿真环境验证修改是否成功

修改程序后，我们只要使用同样的环境进行仿真，并且有针对性的观察bug是否解决。本例中出现bug的原因是使用了异步FIFO，改成同步 FIFO后，问题应该就会解决，我们可以通过仿真验证。

修改后相同的条件FIFO读出4个数，说明没有读空，符合要求，bug解决。图7为版本编译后上板使用SignalTap抓取的信号波形，以作比较。

总结

文中描述的方法可针对各种的故障的解决。在故障出现时，只需定位出错的模块，这些模块内嵌一些子模块也无妨；抓信号时将故障模块的输入输出信号抓出即可；利用输入信号重建故障环境，若仿真输出信号和所抓输出信号相同，说明故障环境建立正确；用这个仿真平台就可以具体定位是哪个子模块、哪个信号出错，而不需要在SignalTap中把这些信号抓出来；并且在修改代码后可以验证是否修改成功，节省时间，很明确的证明故障真的被解决了，事半功倍。