4.7 Design Configuration Management

From a management point of view, the primary objectives of configuration control are:

• Allow the design team to know what changes and updates were made to the design between design versions
• Allow the design team to undo design updates, recover from database corruptions and computer failures
• Support having the entire team working with the same version of the design files

All configuration control version backups should include:

• All design files sufficient to recreate/reconstruct/regenerate the design
• The hierarchy of all files
• Any support files such as design build sequence and dependency notes and script files which automates the FPGA build process
• The path to and contents of any utilized support design library
• The current version and revision level (software patch) for any software tools used
• When the design is “archived” at the end of the project, additional design elements that are readily available to the design team should also be included in the collected database

[endif]--><>Configuration Control Observations

• Many design teams do not take the time to clean older unused files out of active directories
• If design files are not regularly managed and cleaned out, directories can swell to unmanageable sizes
• Many design teams do not develop a directory structure that is inherently configuration-friendly
• There are few 3rd party stand-alone configuration control tools targeting FPGA design
• Many FPGA tools do not have robust full featured built-in configuration control functionality
• In general the configuration control solutions available for FPGA designs lag behind the functionality and features available in commercial software configuration control software
• [endif]-->Some FPGA tool sets support limited interface with commercially available 3^rdparty software configuration control tool suites, but few are fully integrated

One of the biggest challenges associated with FPGA configuration control is making the required difficult and sometimes complex decisions. Making these decisions is easier with the understanding that any configuration control process or plan that is actually implemented is infinitely better than a detailed plan that goes un-implemented, or no configuration control effort at all. Some of the decisions and suggestions to be considered are presented in the following lists.

Configuration Control Decisions

• How frequently should the design be backed up?
• What constitutes a sufficient backup trigger event? Weekly? Major design updates? Etc.
• [endif]-->How will major and minor design “versions” be numbered, tracked and stored?
• Should “all” the files be backed up every time?
• If only “source” files are backed up, which ones are they? How can they be tracked?
• Which team member will be responsible for implementing and verifying that backups have occurred?
• How often will the ability to re-implement a design be verified using only the saved files?

Configuration control for an FPGA design is in some respect a more complex challenge than configuration control for a conventional processor project. The file types and relationships are more complex and more proprietary than with conventional programming relationships. Manufacturer tools do not currently implement FPGA design configuration control solutions with the same level of features and ease-of-use of programming configuration control solutions. Third-party development tools may implement better configuration control solutions for certain FPGA manufacturers. Following are some configuration control suggestions.

Configuration Control Suggestions

• Set aside schedule and budget to verify that all files required to rebuild the design from scratch are included in the design backup at least once
• [endif]-->Make sure that, as new source design files are added to the design, they are included in all subsequent backups (If possible automate this process based on hierarchy or file extension types)
• Keep all required files under a common directory structure since it is generally easier to “roll-up” a directory hierarchy
• If outside library directories are used, make sure to include those in the backup if they are regularly updated
• Make informed decisions (and policy) to determine the file directory hierarchy for the design rather than simply letting an ad-hoc directory structure develop. File hierarchies are very difficult to change mid-project
• Set up a file hierarchy that can easily expand and adapt throughout the life of the project
• Develop and adhere to a common, agreed-on file-naming convention to be used by the entire design group
• Develop and adhere to a common agreed on signal naming convention to be used by the entire design group
• If possible use the same (or very similar) names at the PCB/board level and FPGA top-level
• If possible use the same (or very similar) names at lower FPGA module levels as used at the FPGA top level
• If the names do not match, develop and maintain a level-to-level signal translation (relationship) table or database
• If files are shared between designs, consider making local directory copies so that each design is complete and independent
• If common design files must be maintained between projects, manage changes very carefully to common files and make sure to include the files in design backups
• A simple configuration control approach can consist of simply zipping all the appropriate design directories (maintaining the file path hierarchy)

4.7设计配置管理

（译者注：在下文中，“配置控制”可以等价 于“版本控制”，但是“配置管理”的概念大于版本控制包含的内容）

从管理的角度看，配置控制的首要目标是

1. [endif]-->让设计团队可 以回退到项目历史上任何一点对应的设计的先前版本上

1. 让设计团队可 以获悉在设计版本之间对设计做了哪些改变和更新
2. 让设计团队可 以撤销对设计的更新，可以在数据库崩溃或计算机宕机后恢复工作
3. 让整个团队可 以工作在设计文件的同一版本上（而不发生冲突）

所有配置控制的版本备份应该包括

1. 所有的设计核 心文件，从这些文件足以重新创建和生成完整的设计
2. 所有文件的层 次结构
3. 所有的支持文 件，比如设计构建的顺序和依赖性记录和自动化FPGA构建过程的脚本
4. 用到的任何设 计支持库的路径和内容
5. 使用过的任何 软件工具的当前版本和修订级别（软件补丁）
6. 当项目结束时 对设计进行归档时，对设计团队来说是随手可用的额外的设计元素也应该包括在已被收藏的数据库中

对复杂的FPGA项目的配置控制和管理，是一项意义重大，具有压倒性的任务，但是由 于其复杂性而常常被忽视。配置管理具备完成两个主要功能的能力： 从设计或文件损坏中恢复的能力，和回退到设计周期中某个先前点的能力。后一种需求即使在文件没有损坏的情况下也是存在的。

在某些案例中，个别的设计者会特意限制或避免使用配置控制，因为他们把配置控制看作是一个不必要的负 担或是设计效率的拖累。配置控制是高效的可重复的设计周期中的关键路径。配置控制提供了在设计元素损坏需要回退到设计先 前版本时访问所需文件的通道。在设计投产后，接触不到原有的设计团队的情况下，配置管理也提高了新设计团队重构和更新设计的能力。

另外一个益处是可以通过配置控制制定更佳的对未来项目的内部估计方法。为了评估一个项目的进展和曾经 遇到的挑战，能够获得设计数据库在设计全程中变化的精确记录是很重要的。

维护设计数据库的配置控制过程的相关考虑因素很多。为了实现一个全面的配置管理过程，一些问题需要项 目管理者做出决定来解决。下面就是在维护一个配置控制过程中重要的考虑因素和需要解决的问题的清单：

配置控制重点问题列表

1. 针对FPGA设计过程的配置控制会更富挑战性。 这是因为涉及到众多的文件类型，并且这些文件的复杂交互关系在不同工具集和FPGA厂商之间也有所不同
2. 许多设计团队 没有花时间清理活跃的文件目录中无用的旧文件
3. 如果不对设计 文件进行定期的管理和清理，文件目录就会不断膨胀以致无法管理
4. 许多设计团队 没有制定本质上是配置友好的文件目录结构
5. 缺乏针对FPGA设计开发的独立的第三方配置控制工 具
6. 许多FPGA设计工具缺乏稳健的全功能内建配置 控制功能
7. FPGA设计可用的配置控制解决方案提供的功能和特性整体上落后于商用的软件配置管理工具
8. 有些FPGA设计工具提供对市售的第三方软件配 置管理工具套件的接口，但是功能有限，更没有能够做到全面集成的

FPGA配置控制面临的最大挑战之一是做出必需的困难和复杂的决定。如果能够明白任何付诸实现的配置控制过 程或计划都远比虽然详细但是没能实现的计划好得多，更远胜于没有任何配置控制的过程，那么做出这些决定就容易多了。下面的清单给出了需要加以考虑的决定和 建议：

配置控制决定

1. 选用的FPGA设计工具自带的配置控制特性是否足 够好？
2. 设计备份的频 率是怎样的？
3. 在何时和那些 情况下需要进行新的备份？一周一次？主要的设计更新？或是其他？
4. 主要和次要的 设计版本如何编号、记录和存放？
5. 怎样设计文件 目录结构来简化备份过程？
6. 每次备份都要 针对全部的文件进行吗？
7. 如果只需要对 源文件进行备份，如何确定它们的类型？如何记录它们的变化？
8. 由谁来负责实 现备份？由谁来验证备份的有效性？
9. 备份文件的完 整性，即仅通过备份文件来重新实现设计的能力，需要多长时间验证一次？

针对FPGA设计的配置控制在某些方面是比传统的基于处理器的项目的配置控制更复杂的挑战。文件类型更加复杂，与 传统的软件或嵌入式编程相比，文件关系更具专有性。FPGA厂商提供的工具中实现的配置控制方案在功能和易用性上还未能达到软件编程中采用的配置控制方案的水 平。第三方开发工具对某些FPGA厂商可能实现了更好的配置控制方案。下面是一些配置控制建议：

配置控制建议

1. 分配时间和预 算来至少一次验证所有从头重建设计的必需文件都包含在备份中
2. 确保设计中新 添加的源文件及时被包含进随后的备份中（有可能的话，基于层次结构或文件类型扩展名来自动化这一过程）
3. 确保配置备份 保持了文件的相对路径和目录结构
4. 把所需的文件 放置在统一规划的目录结构下，这样做通常使得建立层次化的目录结构更容易
5. 如果使用了外 部库文件，确保在备份中包含这些库文件，以防外部库文件更新后找不到原有的库文件
6. 制定广泛获悉 的决定（和方针）来确定设计的文件目录层次，而不是简单地放任一个即兴的目录结构随意发展。在项目进行到一半的时候，就很难对文件的层次结构进行变更了
7. 文件目录的层 次结构在项目的生命周期中应该建立得具备可扩展性和适应性
8. 制定并坚持统 一的共识的文件命名约定，确保全体设计成员使用之
9. 制定并坚持统 一的共识的信号命名约定，确保全体设计成员使用之
10. 尽可能在PCB板级和FPGA顶层采用相同或相似的信号名称
11. 尽可能在FPGA底层和FPGA顶层采用相同或相似的信号名称
12. 如果不能做到 上述的统一命名，那么就制定并维护一个层与层之间的信号名称（关系）对照表或数据库
13. 如果文件在设 计之间共享，考虑建立本地拷贝，确保各个设计是完整和独立的
14. 如果在设计之 间必须维持共享的通用文件，那么需要谨慎地管理这些共享文件的变更并确保在设计备份中包含进这些文件
15. 简单的配置控 制方法可以由仅仅压缩所有的恰当的设计目录组成（在压缩文件中要保持文件的路径层次）