4.7.1Controlling the FPGA Design in the Lab

With the freedom to change, recompile and reload the FPGA design to a board comes the responsibility to keep track of changes and keep FPGA design versions under configuration control. It is not enough to always have access to the latest design FPGA version. Occasionally it may be necessary to go back ten or more versions of the FPGA design to revisit a specific problem or subsequent fix. This can only be accomplished if versions of the FPGA design are well documented and carefully stored away for future retrieval. Board configuration control factors are listed below.

• <> <> <> Change description, reason for change and who made the change, current revision of the design, date, time, etc

This responsibility is further complicated when multiple versions of the target hardware exist, which require different versions of the FPGA design. For example, if a board update to a hardware design requires swapping an input and output between two FPGA pins, the FPGA versions for the modified board will have to be different than those loaded onto the unmodified board. Loading the wrong FPGA version to a board could result in unpredictable behavior or component damage.By careful FPGA design configuration management and part programming and tracking, serious problems can be avoided.

Once the FPGA design has been captured and compiled and initially downloaded to the HW target, configuration tracking needs to be maintained at the board level in the lab. Efficient real-world debugging is much easier when as many variables as possible are removed when trying to determine the source of a problem.

Logbooks should be maintained with each prototype board and these logs should be kept up-to-date. Information in the logbooks should include detailed information when a problem is encountered. What version of the software is running a test? Which board was the test run on? Who ran the test? What host unit was the board installed in? What test equipment was attached to the board? What version was loaded into the FPGA? What was the white-wire configuration of the board at the time of the test? Was the problem consistent or intermittent? What system settings or specific sequence of events seem to affect the occurrence of the problem? Obviously these are difficult things to keep track of, but if this information is accurately recorded and good configuration control is implemented, it should be possible to re-create specific problem configurations, which can be invaluable in tracking down problem sources and testing subsequent solutions.

Keeping track of the state of the board and other system variables can be just as important as knowing what version of the FPGA was loaded at the time of a specific fault or failure. In other words, when a problem occurred did it have the latest group of hardware modifications? Was it running older controller code? Had the board just returned from rework and not been fully tested? The answers to these questions can help identify system problem sources.

4.7.1在上板调 试过程中对FPGA设计进行配置控制

FPGA设计可以自由地加以改变、重新编译和重新加载到电路板上，由此而来的责任是记录变更和保持FPGA设计的版本在配置控制之下。总是能 够得到最新的FPGA设计是不够的。偶尔会有必要回退十个甚至以上的FPGA设计版本来再现某个具体问题及随后相应的解决方法。只有对FPGA设计进行归档并小心保存以备将来检索 才能实现上述目标。下面列举了板级配置控制的因素：

1. [endif]-->FPGA设计文件必须保持在配置控制之下，这样才能在以后重建任何构建

1. 针对不同的电 路板版本，需要维护不同的FPGA设计版本链或 “版 本树”
2. 这就需要一个 高效、有效的方法来把针对一个设计版本链进行的设计更新传递到所有当前可以使用的FPGA设计之中
3. 设计的各个版 本中应该包括内建的设计变更历史文档
4. 历史文档应当 包括：改变的描述，改变的原因，谁做出了改变，当前的版本、日期、时间等等

当存在目标板的多个版本时，相应地就需要FPGA设计的多个版本，记录变更和配置控制的任务就变得更加复杂了。例如，当电路板设计修改后需要交换FPGA两个引脚的输入输出关系，那么针对 新旧两款电路板就会存在不同的FPGA版本。下载错误的FPGA版本到电路板上会导致不可预知的行为或器件损坏。通过谨慎的FPGA设计配置管理和谨慎的器件编程和跟踪，是可以避免严重问题出现的。

当FPGA设计完成了设计捕获、编译并第一次下载到了目标电路板上，就需要在实验室中开始维护板级配置跟踪文 档。当试图确认问题的源头时，尽可能多的排除可变因素，就更容易实现高效的实际调试。

针对每一个原形电路板都要维护一个日志记录，这些日志要保持更新。日志记录中的信息应该包括问题发生 时的详细信息。运行的测试软件是什么版本？测试是在哪个板子上运行的？测试是由谁运行的？板子安装在了哪个主机单元上？板子上附接了什么测试设备？FPGA中加载了什么版本？测试时板子上的 飞线（white wire）连接方式是怎样的？问题是持续出现还是偶然出现？怎样的系统设置或具体的事件序列看上去会影响问题的出现？显然，上述信息是很难在事后靠记忆 整理追溯的，但是如果这些信息在日志中记录得准确而且实现了很好的配置控制，应该有可能重现具体问题发生的配置环境。能够重现配置环境，对于查找问题的源 头和测试相应的解决方案是非常宝贵的。

记录具体故障和失败发生时板子的状态和其它的系统变量就和清楚加载了哪个FPGA版本一样重要。换言之，当问题发生 时，对板子是否进行了最近的一组硬件修改？是否运行了老版本的固件代码？板子是否刚刚返工回来，还没有进行全面的测试？对这些问题的回答有助于确认问题的 源头。