Process · General Industry
Configuration management
The discipline of identifying the items that make up a product, such as requirements, design files, software, tools and documents, controlling changes to them and recording which versions form each baseline and release, so that what was built and tested can always be traced.
- Also known as
- Configuration control
- Type
- Process
- Domain
- General Industry, Design and product flow
Overview
Configuration management is the discipline of identifying every item that makes up a product, controlling changes to those items and recording which versions belong together in each baseline and release. On a chip project the items include specifications, RTL, IP blocks, libraries, scripts, tool versions, test programs and documents. Its purpose is that the team can always say exactly what was built, verified and shipped, and rebuild it if needed.
How it works
The classic discipline has five parts. Planning sets the rules: what is controlled, how items are named and who approves changes. Identification gives each item a unique name and version and defines baselines. Change control evaluates proposed changes before they are made. Status accounting records the current version of everything and any departures from the baseline. Verification and audit check that the product matches its documented configuration.
In chip design, version control systems hold the source files, and design data management tools tie together the RTL, third party IP releases, process design kit versions and generated views that make up a tapeout. Baselines are typically frozen at milestones such as RTL freeze, netlist release and tapeout, so that any later bug can be traced to the exact files and tool versions that produced the silicon.
The hard parts are scale and dependencies. A large SoC combines many IP blocks, each with its own release cycle, and a change in one block or a tool update can affect others without any visible sign. Spreadsheets do not cope at this scale, which is why dedicated tools and disciplined release processes are used.
Examples
- A tapeout release that records the exact RTL tag, IP versions, PDK release and tool versions used to produce the layout sent to the foundry.
- A metal-layer fix after first silicon, handled as a controlled change with impact analysis and a new baseline.
- A production test program released under version control so every tested part can be linked to the program that tested it.
- A security-focused configuration baseline for engineering servers, following NIST guidance.
Why it matters
Without configuration management a team cannot be sure that the database sent to the foundry contains the fixes that verification signed off, or rebuild an older product for a customer. Configuration management engineers, CAD and release teams and quality staff run it, and safety and security frameworks treat it as a required supporting process, because a safety or security argument holds only for a known configuration.
In the chip lifecycle, configuration management starts with the first specification baseline, controls every design and verification release, fixes the tapeout database and test programs for production, and keeps the records through derivatives, changes and end of life.
It matters most to: Change Control / ECR-ECN Manager, Configuration Management Engineer, Quality Systems Engineer, Software Configuration and Build Engineer, Software Integration and Release Engineer
Common confusions
- Not the same as version control
- Version control tracks changes to files. Configuration management decides which versions of which items together form an approved baseline, and controls how that baseline changes.
- Not the same as change management
- Change management, the evaluation and approval of changes, is one part of configuration management. ISO 26262 lists the two as separate supporting processes.
- Not the same as device configuration
- Setting registers, fuses or straps to configure a chip for an application is device configuration, which has nothing to do with this discipline.
Related standards
- ISO 10007 (guidelines for configuration management)
- ISO 26262-8 (road vehicles functional safety: supporting processes)
Sources
- ISO 10007:2017 Quality management, Guidelines for configuration management (opens in a new tab), ISO, 2026-10-22
- ISO 26262-8:2018 Road vehicles, Functional safety, Part 8: Supporting processes (opens in a new tab), ISO, 2026-10-22
- SP 800-128, Guide for Security-Focused Configuration Management of Information Systems (opens in a new tab), NIST, 2026-10-22
- Version Control Nightmares (Ed Sperling, 16 December 2010) (opens in a new tab), Semiconductor Engineering, 2026-10-22
- Configuration management (Wikipedia) (opens in a new tab), Wikimedia Foundation, 2026-10-22
Related terms
Part of the General Industry glossary, with every term in the topic and the lifecycles, tools and standards that use them.
Where it appears on the Hub
Used on 29 pages of the Hub. In each group, the pages that mention it most come first.
Lifecycle stages and gates
- Certification Planning (Avionics lifecycle)
- Project Planning, Quality & Configuration Set-up (Automotive SPICE lifecycle)
- Plans submitted (Avionics lifecycle)
- Project plans baselined (Automotive SPICE lifecycle)
- Detailed Design, Units & Unit Verification (Automotive SPICE lifecycle)
- Hardware and Software Requirements (Avionics lifecycle)
- and 5 more
Roles
Suggest an improvement
Suggest an improvement to this entry
A clearer definition, an example, a correction or a source an editor can check. Editors review every suggestion before the entry changes.
Last reviewed . Written by The Semiconductor Hub editorial team. The full glossary