原创 [译完] Rapid System Prototyping with FPGAs - 4.7.1

4.7.1 Controlling 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.

• FPGA design files must be kept
  under configuration control so that any specific build can later be recreated
• Different FPGA design chains or
  “trees” may need to be maintained for different board versions
• This requires an efficient,
  effective way of propagating design updates made in one design chain to all
  current operational FPGA designs
• Design versions should include
  built-in documentation of the design change history including:
• 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.        
FPGA设计文件必须保持在配置控制之下，这样才能在以后重建任何构建

2.        
针对不同的电路板版本，需要维护不同的FPGA设计版本链或 “版本树”

3.        
这就需要一个高效、有效的方法来把针对一个设计版本链进行的设计更新传递到所有当前可以使用的FPGA设计之中

4.        
设计的各个版本中应该包括内建的设计变更历史文档

5.        
历史文档应当包括：改变的描述，改变的原因，谁做出了改变，当前的版本、日期、时间等等

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

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

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

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