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

4.7.2 Archiving the Design

After the project has been completed, but
before the design team is reassigned, a project design archiving should be
generated. A complete archive should
include all the functionality listed for a complete configuration version
backup plus the source disks for all essential software tools, all software patches,
design updates, known tool issue work-arounds, tools, design estimates
including schedule, manpower and budget, manufacturers documentation, and all
other technical content or effort associated with the development effort. The archived
design should include all files required to implement a version of the design
in the future, including a version of the OS (with installed patches) and all
hardware and software keys. For completeness, all design notes, board
layout files, development and production documentation and databases, component
datasheets, user’s guides and component errata should also be included. By definition,
at the end of a project all the information and knowledge required to implement
that project should be readily available. As the years pass, much of the
information will cease to be available and access to the original design team
will also be reduced. The budget to completely archive a design should be set
aside in management reserve when a project is started. If there is any
significant possibility the design will need to be updated or leveraged in the
future, the investment in wrapping up a design immediately after it is
completed will likely be exponentially less than it will be at any time in the
future. A summarized list of design archive content for a design is shown in
the following list.

Design Archive
Considerations

• Design hierarchy
• Design file descriptions and
  relationships
• A script file which automates
  all or part of the design build sequence
• All source files required to
  reconstruct the final versions of the design
• Clearly identified final
  versions of all files to eliminate ambiguity
• A list of all design tools,
  version numbers, revision states
• All design tool license files,
  hardware keys and license installation instructions
• The original source media for
  all design tools and revision updates (no dependency on the internet, internal
  computer network or specific computer for any files)
• Complete final design source
  and output file database with clearly identified final file versions
• Hardware equipment version
  number required to download and interface to the target board
• Design Flow Documents
  including: A documented procedure/process for converting and downloading the
  placed and routed design to the target board with step-by-step instructions and
  required tool settings
• Source code and documentation
  for all IP utilized in the design
• Tools required to implement and
  integrate IP functions within the design
• IP license agreements, keys and
  software key installation procedure
• A golden design disk containing
  the critical source files and clearly labeled final FPGA image file(s)
• A clearly and completely
  documented design build sequence
• Design documents including the
  final version of: unit operation manual, final board schematics (including
  white-wires and board modifications), design integration, test plans,
  requirements, testing procedures, and verification matrix, and design review
  documents

A complete
design archive can be trusted only when the entire load sequence has been
verified on an unconfigured computer (preferably including the loading of the
PC’s operating system and any patches or updates required to support the FPGA
design tool operation). This may take several hours but will identify any
missing source data or documentation at a time when fixing the problem will be
cheaper than at any time in the future.

Verify and re-verify
the FPGA I/O signal assignments against the PCB FPGA schematic symbol. Ideally,
a final cross check should be done between the final post layout and route FPGA
report files and the final PCB board netlist. It is possible there may have
been some back and forth FPGA pin changes during the PCB layout process,
however, after the PCB has been released to be fabricated no more FPGA I/O
assignment changes can be made. While every effort must be made to make sure
that the I/O assignments don’t change (usually the I/O assignments are located
within a design constraint file) the final PCB release I/O assignments should
be documented and again verified before the first FPGA device image is
downloaded to the target hardware board. If
the pin assignments within the FPGA do not agree with the implemented design at
the board level, damage can occur to either the FPGA component or the
board-level circuits.

4.7.2 把设计存档

项目完成后，设计团队分配新任务前，需要对项目的设计进行归档。最基本的归档应该包括通过配置控制（版本控制）工具取得的功能完整的版本的备份，加上所有关键软件工具的安装盘，所有的软件补丁，设计更新，已知问题的处理措施、工具，包括日程、人力和预算在内的设计评估文档，厂商文档，和所有其它与开发过程有关的技术内容或开发成果。设计归档应该包括在未来重现该设计某一个版本的所有必需的文件，包括操作系统的一个版本（安装了补丁）和所有的硬件“狗”和软件安装序列号。为了归档的完整性，还应该包括所有的设计笔记，电路板版图文件，开发和生产文档和数据库，器件数据手册，用户指南和器件勘误表在内。在项目完成时，所有用以实现该项目的必需的信息和知识自然都是齐备的。但是几年过去之后，许多信息就很难找得到了，原有的设计团队也越来越不容易接触得到。当项目启动时，就应该分配预留的经费用以对设计进行完整的归档。如果在未来有对该设计进行更新和利用的显著的可能性的话，在设计完成之际对设计归档所需的投资比在未来任何时候对设计归档所需的投资都会成指数减小。下面的列表总结了设计归档所需的内容：

设计归档考虑因素

1.        
设计的层次结构

2.        
设计文件内容和相互关系的描述

3.        
用以自动化顺序构建部分或全部设计的脚本

4.        
重建设计最终版本所需的全部源文件

5.        
定义明确的所有文件的最终版本号，以消除歧义

6.        
设计工具列表，及其版本号，修订状态

7.        
所有设计工具的许可文件，硬件“狗”和许可文件安装说明

8.        
所有设计工具的原始安装媒体和修订更新（任何文件都不能依赖于互联网、内部计算机网络、或特定的计算机来获得）

9.        
设计源文件和输出文件完整的最终数据库，这些都需要有一个明确的最终版本号

10.    
对目标板下载和连接所需的硬件设备的版本号

11.    
设计流程文档，包括：记录在案的对布局布线后的设计进行转换和下载至目标电路板的程序/过程，应该包含详细的操作步骤和必要的工具设置

12.    
设计中用到的所有IP的源代码和文档

13.    
在设计中实现和集成IP功能的必需的工具

14.    
IP授权协议，硬件“狗”和软件序列号安装程序

15.    
一个包含关键源文件和标示明晰的最终FPGA映像文件的“金质”设计光盘

16.    
一个清晰完整的设计构建次序文档

17.    
所有的设计文档，包括最终版本的产品操作手册、最终电路原理图（包含飞线和电路板更改），设计集成和测试计划，需求文档，测试步骤和验证列表，设计评审文档

只有在一台“干净”的（未经配置的）计算机上（最好重新安装PC机的操作系统和用以支持FPGA设计工具操作的必要的补丁或更新），对整个加载流程进行了验证，一个完整的设计归档才是可以置信的。虽然这么做会花费数个小时，但是通过验证可以发现任何缺失的源数据或文档，这时修复这些问题花费的代价比在将来任何时候都要小。

反复验证FPGA的I/O信号分配与PCB上的FPGA封装符号是一致的。理想的情况下，最终的交叉检查应该在最终的FPGA布局布线后报告文件和最终的PCB网表之间进行。在PCB版图设计过程中，有可能会有一些反复的FPGA引脚变更，但是，当PCB发布并送交生产后，就不能对FPGA的I/O分配进行任何修改了。在确保I/O分配不发生变化的同时（通常I/O分配会保存在一个设计约束文件中），最终发布的PCB上的I/O分配也应该归入文档，并在第一次下载FPGA映像文件到目标电路板之前，再次进行验证。如果FPGA上的引脚分配与在电路板一级实现的设计不符的话，就会损坏FPGA器件或电路板上的外围器件。