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

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

　　问题的提出

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

　　这样就会出现三个问题：

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

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

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

　　举例说明：

　　图1 signaltap抓出的bug出现时的数据

　　图2 signaltap抓信号界面

　　例如在一个基带系统的fpga逻辑版本中，输出模块调用了一个异步fifo，某一时刻fifo已空的情况下多读了一个数据，产生了bug，如图1所示。

　　该输出模块的功能是判断fifo中是否有大于4个数据可读出，若大于则连续输出4个数据作为一组。系统中采用异步fifo的内部读数据指针来做判断，而异步fifo读写数据需要跨时钟域，需要至少2个时钟周期的握手时间，导致数据指针不准确。在判断的时钟沿，虽然显示有超过4个的数据可读，但是因为握手时间的延迟实际上fifo中可能只有3个数据。

　　图1中rdreq为fifo的读使能信号，在4个时钟周期内有效，但是只读出了3个数（数据0d2086c9f被读了两次），因为fifo在第4个时钟周期已经读空。这里应该改成同步fifo，由于同步fifo数据的读写只在一个时钟域内进行，就没有这个握手时间延迟的问题了。

　　定位这个故障的时候我们可以很容易知道是哪个模块出了问题，但是具体是其内部的哪个信号还需要下些功夫，如果出错信号隐藏的很深，很难一次就抓到需要的信号；而且即使我们抓到了正确的信号，如果故障在改完之后没有解决，则还需要重新修改、再进行编译，耗费时间；即使改过之后故障不再复现，也有可能是因为bug出现的条件苛刻，无法证明故障真的解决了。

　　针对这三个问题，笔者提出如下想法：

　　虽然定位具体的出错信号很困难，但是定位是哪个模块出错很容易，在bug出现的时候我们可以抓出这个模块的全部输入信号，考虑是否可以利用这些信号在仿真环境下重建bug出现的条件，利用仿真环境具体定位错误信号的位置。

　　定位好错误信号的具体位置后，修改代码，再用相同的条件进行仿真。这样可以通过对修改前后输出数据的对比，很直观的验证修改是否成功，从而在修改成功后只需编译一次即可，节省时间。

　　上板后bug不复现也可以排除是由于极端情况很难满足造成的，去除了后顾之忧，彻底解决了故障。

　　仿真解决故障的方法

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

　　图3 signaltap ii list file界面

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

　　quartus ii 平台用signaltap抓到信号的界面如图2所示。

　　在信号名称上单击右键，选择图2所示create signaltap ii list file选项，生成如图3格式界面。

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

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

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

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

　　问题的提出

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

　　这样就会出现三个问题：

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

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

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

　　举例说明：

　　图1 signaltap抓出的bug出现时的数据

　　图2 signaltap抓信号界面

　　例如在一个基带系统的fpga逻辑版本中，输出模块调用了一个异步fifo，某一时刻fifo已空的情况下多读了一个数据，产生了bug，如图1所示。

　　该输出模块的功能是判断fifo中是否有大于4个数据可读出，若大于则连续输出4个数据作为一组。系统中采用异步fifo的内部读数据指针来做判断，而异步fifo读写数据需要跨时钟域，需要至少2个时钟周期的握手时间，导致数据指针不准确。在判断的时钟沿，虽然显示有超过4个的数据可读，但是因为握手时间的延迟实际上fifo中可能只有3个数据。

　　图1中rdreq为fifo的读使能信号，在4个时钟周期内有效，但是只读出了3个数（数据0d2086c9f被读了两次），因为fifo在第4个时钟周期已经读空。这里应该改成同步fifo，由于同步fifo数据的读写只在一个时钟域内进行，就没有这个握手时间延迟的问题了。

　　定位这个故障的时候我们可以很容易知道是哪个模块出了问题，但是具体是其内部的哪个信号还需要下些功夫，如果出错信号隐藏的很深，很难一次就抓到需要的信号；而且即使我们抓到了正确的信号，如果故障在改完之后没有解决，则还需要重新修改、再进行编译，耗费时间；即使改过之后故障不再复现，也有可能是因为bug出现的条件苛刻，无法证明故障真的解决了。

　　针对这三个问题，笔者提出如下想法：

　　虽然定位具体的出错信号很困难，但是定位是哪个模块出错很容易，在bug出现的时候我们可以抓出这个模块的全部输入信号，考虑是否可以利用这些信号在仿真环境下重建bug出现的条件，利用仿真环境具体定位错误信号的位置。

　　定位好错误信号的具体位置后，修改代码，再用相同的条件进行仿真。这样可以通过对修改前后输出数据的对比，很直观的验证修改是否成功，从而在修改成功后只需编译一次即可，节省时间。

　　上板后bug不复现也可以排除是由于极端情况很难满足造成的，去除了后顾之忧，彻底解决了故障。

　　仿真解决故障的方法

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

　　图3 signaltap ii list file界面

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

　　quartus ii 平台用signaltap抓到信号的界面如图2所示。

　　在信号名称上单击右键，选择图2所示create signaltap ii list file选项，生成如图3格式界面。

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

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