4.7 Design Configuration Management

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

• <!--[if !supportLists]-->Allow the design team to return to a previous version of the design at any point in the previous history of the project
• <!--[if !supportLists]-->Allow the design team to know what changes and updates were made to the design between design versions
• <!--[if !supportLists]-->Allow the design team to undo design updates, recover from database corruptions and computer failures
• <!--[if !supportLists]-->Support having the entire team working with the same version of the design files

All configuration control version backups should include:

• <!--[if !supportLists]-->All design files sufficient to recreate/reconstruct/regenerate the design
• <!--[if !supportLists]-->The hierarchy of all files
• <!--[if !supportLists]--><!--[endif]-->Any support files such as design build sequence and dependency notes and script files which automates the FPGA build process
• <!--[if !supportLists]-->The path to and contents of any utilized support design library
• <!--[if !supportLists]-->The current version and revision level (software path) for any software tools used
• <!--[if !supportLists]-->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

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

• <!--[if !supportLists]-->Are the selected design tool configuration control features good enough?
• <!--[if !supportLists]-->How frequently should the design be backed up?
• <!--[if !supportLists]-->What constitutes a sufficient backup trigger event? Weekly? Major design updates? Etc.
• <!--[if !supportLists]-->How will major and minor design “versions” be numbered, tracked and stored?
• <!--[if !supportLists]--><!--[endif]-->What directory structure should be implemented to simplify the backup process?
• <!--[if !supportLists]-->Should “all” the files be backed up every time?
• <!--[if !supportLists]-->If only “source” files are backed up, which ones are they? How can they be tracked?
• <!--[if !supportLists]-->Which team member will be responsible for implementing and verifying that backups have occurred?
• <!--[if !supportLists]-->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

• <!--[if !supportLists]-->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
• <!--[if !supportLists]--><!--[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)
• <!--[if !supportLists]-->Make sure that the configuration backup maintains the relative path/directory structure
• <!--[if !supportLists]--><!--[endif]-->Keep all required files under a common directory structure since it is generally easier to “roll-up” a directory hierarchy
• <!--[if !supportLists]-->If outside library directories are used, make sure to include those in the backup if they are regularly updated
• <!--[if !supportLists]--><!--[endif]-->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
• <!--[if !supportLists]-->Set up a file hierarchy that can easily expand and adapt throughout the life of the project
• <!--[if !supportLists]-->Develop and adhere to a common, agreed-on file-naming convention to be used by the entire design group
• <!--[if !supportLists]-->Develop and adhere to a common agreed on signal naming convention to be used by the entire design group
• <!--[if !supportLists]-->If possible use the same (or very similar) names at the PCB/board level an FPGA top-level
• <!--[if !supportLists]-->If possible use the same (or very similar) names at lower FPGA module levels as used at the FPGA top level
• <!--[if !supportLists]-->If the names do not match, develop and maintain a level-to-level signal translation (relationship) table or database
• <!--[if !supportLists]--><!--[endif]-->If files are shared between designs, consider making local directory copies so that each design is complete and independent
• <!--[if !supportLists]--><!--[endif]-->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
• <!--[if !supportLists]-->A simple configuration control approach can consist of simply zipping all the appropriate design directories (maintaining the file path hierarchy)

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。