FPGA之道（20）FPGA设计的上板调试与项目总结

文章目录

前言
FPGA设计的上板调试
- “实践是检验真理的唯一标准”
- 如何解决问题
- 如何找到问题
- “时间是检验真理的第二标准”
项目总结、备份与后期维护

前言

上板调试几乎是项目的尾声了，这一步是检验最终成果的时候，可是这一步却不像想象的那么容易，耗时耗力，莫名其妙的bug折磨着你，考验FPGA开发者的心智。再加上抱怨，可能会导致一个人的崩溃。哈哈，本人就曾被一个bug围困几个月之余，而最后的问题其实也在意料之中，但就是疏忽掉了，之后得到的一个教训就是不要怕麻烦，仔细检查一切可能的问题。
本身对于FPGA的上板调试就是一个经验活，项目经验丰富的老手能更快的锁定bug的内因，但尽管如此，一般性的准则还是有的，下面摘自《FPGA之道》，让我们一起看看作者对于上板调试的肺腑之言。

FPGA设计的上板调试

到了这里，FPGA基本开发流程的介绍就已经快接近尾声了，但是如来佛祖掐指一算，发现咱们“九九八十一难，还差一难，尚不能修成正果”，于是大手一挥，带来了这最后一难——FPGA设计的上板调试环节。

“实践是检验真理的唯一标准”

在经历了漫长的研发与验证工作之后，我们终于迎来了最关键，最激动人心的时刻——上板调试环节。俗话说“真金不怕火炼”，一路走来，相信你对自己的设计早已自信满满了，你也许早已迫不及待的启动了开发板的电源，连接好了JTAG下载线缆，期待着它的表现。但是，我要告诉你，系统能够如你所愿的工作的概率并不大。如果你发现系统并没有按照你预想的方式工作，请不要灰心丧气，因为这其实很正常，否则上板调试环节的存在也就没有意义了。赶上悲催的时候，花在上板调试环节上的时间可能比之前所有环节加在一起的时间都要长，因为理论和实际之间毕竟是有一定距离的，所以做为一名FPGA开发者，要具有这样的觉悟。所谓“兵来将挡，水来土掩”，只要我们不惧怕问题，灵活运用各种上板调试手段，再加上坚韧毅力的支撑，相信成功就在下一秒！接下来我们就来简要介绍一下如何解决上板调试环节中碰到问题。

如何解决问题

上板调试时碰到的问题千奇百怪、五花八门，针对每一个问题，解决方法都有其一定的特殊性、局限性，不过周总理说得好，我们可以求同存异，因此在这里，还是可以概括几点基本的问题解决方法，供大家参考。

一、开发板状态检查。
系统有问题，第一步就是要先检查开发板是否工作正常，因为对于开发板来说，FPGA芯片只是其中的一部分，其它部分出问题也会导致系统不正常。当然在此之前，请先确定你使用的开发板经过了预测试。什么是预测试？就是在开发板正式投入FPGA设计调试之前，先针对开发板编写一些功能较为简单的FPGA测试设计，通过跑通这些测试设计来确保整个开发板的硬件环境运转正常。所以调试FPGA设计时，一定要使用经过预测试的开发板作为载体，否则问题百出不说，烧毁芯片、引爆电容等等都不是什么稀奇事。虽然使用了通过预测试的开发板，但是现实的东西，使用中就会被消耗、被磨损、被破坏，以前好好的东西现在出了问题也是常有的事，因此当系统有问题时，还是应该在第一时间对开发板进行问题的排查，基本步骤包括但不限于如下几点：

首先，要对系统进行断电检测，主要检查电源和地之间是否有短路、同一网络之间是否有断路等，确认无误后才能上电。
其次，“电路！电路！没有电就没有路！”，上电后立马使用万用表等工具确认开发板中各个电源网络的电压值是否正常，如果供电不正常，谈别的都没有意义。
第三，确认好FPGA的外围电路是否正确：例如是否有虚焊、短接、断开等现象； FPGA物理I/O管脚与外围电路连接是否符合管脚约束文件的要求； I/O端口电平标准是否符合设计的要求等等；
第四，确认板上其他芯片工作是否正常，例如板子上还有ARM、DSP等芯片。

二、测试点监测。
如果开发板工作正常，那么就需要集中精力于FPGA上了。一般开发板都会为FPGA设计预留一些监测点，或者多少会有一些探针可触及的焊点。这时候我们就可以利用示波器、逻辑分析仪等工具对这些监测点进行波形观察，看是否有异常。首先，要尽可能的监测所有输入FPGA或从FPGA输出的时钟信号，看看这些时钟信号的频率、幅度、稳定性是否满足要求；其次，要监测一些使能信号，看看是否落在了错误的状态中；最后，要检测一些数据信号，看看数据线上是否有有意义的数据传递、如果传递的是数据帧，那么帧结构是否符合预期等等。

三、在线调试
FPGA芯片的管脚数量少则几百、多则上千，内部信号数量更是成指数级增长，即使再怎么设计，一个开发板所能引出的监测点也是非常有限的，因此，FPGA的调试通常都有其自己的“一套”。
FPGA芯片厂商早已考虑到FPGA设计在实际调试时可能会碰到的这种问题，因此，一般都会在FPGA的软件集成开发环境中加入在线调试的功能。例如Xilinx公司ISE集成开发环境中的ChipsScope工具， Altera公司Quartus II集成开发环境中的SignalTap等。这些在线调试工具的原理大致是在FPGA设计中添加专门的代码或IP核用来实现对某些指定内部信号的条件监测（即当设定的条件满足时才开始采集数据），然后通过JTAG接口发送采集命令或者接收采集到数据。在线调试工具的优点就是只要开发板上有JTAG接口，那么想看内部什么信号就看什么信号，对于FPGA设计的上板调试帮助非常之大；缺点就是需要改变我们的FPGA设计，添加后会影响到芯片内部的布局布线。
了解了在线调试工具的工作原理后，其实我们在进行FPGA项目的开发时，也可以有针对性的编写一些自测代码，并让其成为设计的一部分，从而避免使用在线调试工具给设计带来变动。缺点就是需要自己设计测试代码，较为麻烦。

四、设计的分割调试与增量调试。
有些时候，由于FPGA设计本身规模比较庞大，开发板的电路结构也比较复杂，采用之前的调试方法实在难以找到有效线索，那么这个时候，就可以利用化繁为简的调试思路。

首先是分割调试的方法。它的基本原理是将FPGA设计按功能分成若干个部分，对每个部分单独编译生成配置文件，然后上板调试。这样由于每个部分的规模都较原来的设计要小，因此问题解决起来也会相对比较方便，并且也便于问题的定位。当然，具体实现的时候远没我们这里说得这么轻松，甚至需做不少代码的改动。
其次是增量调试的方法。它的思路是先将FPGA设计的功能精简到最简，先上板调试好这个最简设计，以后每添加一个功能，就重新编译、配置、上板调试一次，直到恢复到原先的FPGA设计。这种方法也需要一定量的代码改动，例如一个FIR滤波器模块，为了简化这个功能，我们可以将其内部的所有功能代码注释掉，然后直接将输入与输出连接起来即可。
具体进行上板调试的时候，情况可能比较复杂，单独采用分割调试或增量调试的方法可能并不十分有效，一般需要混合使用，甚至使用其他的需要修改设计的调试方法，所以在具体的应用中需要自己掌控。

如何找到问题

经过了上一个环节的辛苦工作，FPGA设计终于在开发板上正常运转起来了，是不是非常兴奋呢？恨不得赶紧举行一个庆功宴，好好放松一下！别急，庆功的事情还是先放一放吧，目前的首要任务是趁热打铁，继续调试！可是没有碰到问题怎么调试呢？没关系，有问题我们就调试，没有问题创造问题也要调试！就是这样，你没有看错，我也没有写错！做项目，一定要有居安思危的意识，问题并不可怕，可怕的是发现不了问题！相信大家对“丰田召回门”都有所了解吧，如果你不对自己开发的产品进行充分的测试，等到客户在使用中发现了问题，那么损失的可就不仅仅是召回几个产品这么简单。
产品测试是一个非常重要的环节，也是一项非常专业的环节，对于我们开发FPGA项目也是一样。作为一名FPGA开发者，我们要对自己的项目负责，虽然受限于时间、项目复杂度、个人的能力和细心程度等，我们不可能将所有潜在的不安因素揪出来，但是请尽力而为吧。因此在这里，简要列举一些查找问题的思路供参考。

首先，通过全面的测试来查找问题。
这点的思路类似于“时序仿真”，但是由于运行在硬件实体上，所以执行效率非常之高，可能只需要1秒钟的时间就能完成时序仿真需要几天才能完成的工作。一个FPGA项目往往由许多基本的功能组成，为了便于问题的查找，我们应该先对系统的功能进行细化，然后针对每个细节功能设计测试方案进行实际测试，这样比较有利于测试覆盖率的提高，从而也就比较容易发现一些细节性的问题。
其次，通过重复的测试来查找问题。
有些时候，同样的功能测试执行一次可能没有问题，但是执行多次就不一定能够保证总不出问题。因此，通过重复性的测试，可以发现一些关乎系统稳定性的问题。
第三，通过综合的测试来查找问题。
有些时候，单独测试功能一是正常的，单独测试功能二也是正常的，但是同时测试这两个功能时，可能由于互相之间的一些影响就会导致FPGA设计出现问题。因此，通过综合测试，可以让我们找到设计中的一些缺陷问题。
第四，通过非法的测试来查找问题。
由于我们是FPGA项目的开发者，所以我们清楚它的一切，因此我们会不自觉的按照正确的操作方法来对设计进行测试，这无形中就降低了测试的覆盖率。可是，产品的最终使用者是客户，正所谓“喜欢看电视的不一定懂电视原理，喜欢用iphone的不一定懂手机原理”，你崩指望客户能老老实实熟读产品操作指南然后小心翼翼的使用产品。所以，在测试的过程中，我们需要通过一些非常规的、不合法（注：此“法”非法律之法）的操作来找出系统在异常情况下暴露出的问题。
最后，恭喜你发现了新的问题，请开始着手解决吧！

“时间是检验真理的第二标准”

任何真理都必须能够经受得住时间的考验，例如，人们最开始都以为地球是方的，后来随着科技的进步，才发现地球原来是个球体。所以在上板调试时，我们的FPGA设计也必须要经过时间的检验，例如让其48个小时、甚至更长时间的连续运转，看是否会出显问题。由此可见，时间考验也是一种查找问题的好方法，但是除此以外，它有其自身的特殊性，所以将它单独列举在这里进行介绍。
简要的讲，时间考验除了可以发现FPGA设计中的一些不稳定因素，还可以发现系统的耐久性问题，这有点类似于复合木地板的打磨测试。这就好比如果你给客户承诺——“我们的产品质保三年”，你总不希望返修率是100%吧！因此，这里简要介绍几点时间测试时需要注意的地方供参考。

一、注意散热的问题。
任何元器件在上电工作的时候都会产生热量，从而导致开发板温度的上升，而温度的上升对于电子器件的性能会产生很不好的影响。因此，我们需要保证系统具有一定的散热性，同时也要尽量减少系统的热损耗，如果散热量始终小于发热量，那么开发板将会一直升温，直到器件工作异常甚至烧毁电路。为什么神州的笔记本配置豪华，但是价位却很低，而IBM（现在被联想收购，叫Thinkpad）的笔记本配置一般，但价格却贵的离谱？就是因为散热的道理，散热做不好，再好的配置也发挥不出它该有的性能，而且稳定性也会很差。
二、注意器件寿命的问题。
任何器件都有一个寿命问题，在使用中都会出现老化、损耗等现象，那么我们肯定是希望系统的运转会让器件的时间寿命尽量长一些，而时间测试可以帮助我们找到系统中的那些短板。例如，按键的设计，如果一个功能可以通过按1下按键解决，那么就没有必要设定为按10次，这样没两天按钮就坏掉了。指示灯的实现也一样，如果需要通过闪烁来显示信息，没有必要让LED灯闪的过于频繁，每秒一次即可。
最后，请记住，只有经过长期稳定的测试，才能认为系统已经具有了比较高的可靠性和稳定性。如果还有遗漏，那也许只有靠客户的反馈了。God bless you！

项目总结、备份与后期维护

如果通过了上板调试环节，那么整个FPGA基本开发流程才算到了收尾阶段，可以开始庆功和放松了，不过高兴过后，请记住还有一些工作等着我们来完成。作为一名FPGA开发者，每一个他经手的FPGA项目就好像他的孩子一样，因为是他为FPGA设计注入了生命，可是如果“管生不管养”，那么就不是称职的父母。因此接下来，我们将介绍一些项目收尾阶段该做的工作。

一、固化FPGA程序。
由于FPGA设计已经正确、稳定，那么我们就可以不在利用JTAG接口来调试设计，此时，我们可以将相应的配置文件直接下载到FPGA的配置芯片中，这样的话，系统每次上电启动之后，FPGA芯片就会自动配置成设定的功能，系统就可以立即开始正常运转。

二、备份最终版本FPGA工程。
备份的重要性就不用多说了，为了能够在今后需要的时候及时顺利的恢复出上板调试得到的最稳定、最正确的系统，这点工作是必须的。一般来说，我们需要备份最终版本的FPGA工程，因为这包括了最终版本的HDL代码、最终版本的约束文件以及集成开发环节中纷繁复杂的编译选项，甚至包括当时使用的编译器版本，只有这些东西都一致，才能保证恢复出一模一样的FPGA设计。

三、针对最终版本的HDL代码编写代码说明文档。
即使是自己写的代码，一年后回过头再看，也会觉得非常陌生，更别提让别人来看了。由于各种各样的原因，例如在今后的使用中发现了新的问题，客户需求的变动等等，FPGA设计在以后的日子里难免需要不断的维护和修改。尤其是经历了各个验证、调试环节，HDL代码的功能和结构可能已经修改的和FPGA设计方案中描述的大相迳庭，因此，针对最终版本的代码编写一个完整的代码说明文档，的确是一件一劳永逸的事情。

四、进行项目总结。
没有总结就没有提高、没有总结就没有积累。这次费了九牛二虎之力解决的问题，如果总结一下，下次碰到类似的问题时可能就非常顺利的解决。因此项目做完后，进行总结是十分必要的，该环节的输出可以但不限于一些技术文档、心得体会、IP核等。并且可以将自己的项目总结与他人进行交流，从而达到共同提高。