4.7 Design Configuration Management
From a management point of view, the
primary objectives of configuration control are:
- Allow the design team to return
to a previous version of the design at any point in the previous history of the
project
- 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
Configuration control and management of a complex FPGA
project can be an overwhelming task and is often overlooked due to its
complexity. Configuration management provides the
ability to accomplish two main functions: the ability to recover from design or
file corruption and the ability to go back to a previous point in the design
cycle even when the files have not been corrupted.
In some cases, individual designers may go out of their way to limit
or avoid configuration control because they perceive it as an unnecessary
burden or a drag on design efficiency. Configuration
control is a critical path of an efficient repeatable design cycle. Configuration
control provides access to the design files required to go back to previous
versions of the design if elements of the design become corrupted. Configuration
management also improves a new design team’s ability to rebuild the project and
update a design after production, when the original design team is no longer
available.
Another
advantage is the ability to develop better internal estimation methods for
future projects. In order to evaluate a project’s progress and challenges, it
is important to have access to an accurate record of the design database during
the full course of the design. There are many considerations associated with
maintaining a design database configuration control process. Following is a
list of important configuration control considerations and issues that should
be addressed by project management decisions in order to implement a
comprehensive configuration management process.
Configuration Control Observations
- Configuration control for FPGA
design can be more challenging because of the many file types and complex file
interactions that differ between tool sets and FPGA manufacturers
- 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
- Some FPGA tool sets support
limited interface with commercially available 3rd party 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
- Are the selected design tool configuration
control features good enough?
- How frequently should the
design be backed up?
- What constitutes a sufficient
backup trigger event? Weekly? Major design updates? Etc.
- How will major and minor design
“versions” be numbered, tracked and stored?
- What directory structure should
be implemented to simplify the backup process?
- 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
- 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)
- Make sure that the
configuration backup maintains the relative path/directory structure
- 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.
让设计团队可以回退到项目历史上任何一点对应的设计的先前版本上
2.
让设计团队可以获悉在设计版本之间对设计做了哪些改变和更新
3.
让设计团队可以撤销对设计的更新，可以在数据库崩溃或计算机宕机后恢复工作
4.
让整个团队可以工作在设计文件的同一版本上（而不发生冲突）
所有配置控制的版本备份应该包括
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.
简单的配置控制方法可以由仅仅压缩所有的恰当的设计目录组成（在压缩文件中要保持文件的路径层次）
系统分类:
CPLD/FPGA | 用户分类:
| 来源:
原创
该用户于2009/6/7 9:50:27编辑过该文章