WP_Term Object
    [term_id] => 15
    [name] => Cadence
    [slug] => cadence
    [term_group] => 0
    [term_taxonomy_id] => 15
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 424
    [filter] => raw
    [cat_ID] => 15
    [category_count] => 424
    [category_description] => 
    [cat_name] => Cadence
    [category_nicename] => cadence
    [category_parent] => 157
    [is_post] => 1

Hardware Configuration Management and why it’s different than Software Configuration Management

Hardware Configuration Management and why it’s different than Software Configuration Management
by Daniel Payne on 03-23-2011 at 2:51 pm

On Friday I talked with Srinath Anantharaman by phone to gain some perspective on Hardware Configuration Management (HCM) versus Software Configuration Management (SCM), especially as it applies to the IC design flows in use today. In the 1990’s we both worked at Viewlogic in Fremont, CA and in 1997 Srinath founded ClioSoft to focus on creating an HCM system from the ground up.

IC Design Flow – How to Control It

The software industry understands how to control their source code files and projects using commercial or Open Source tools however when we design an IC the types of files and relationships between the files are quite different from the relatively simply software world.

The last chip that I designed at Intel involved design teams located in both California and Japan. We didn’t use any tools to synchronize or coordinate the IC design process between the sites and it made for many phone calls, emails and face-to-face trips to decide on which version of schematics, layout, RTL, behavioral code and stimulus were considered golden. We could’ve really used some automation to enforce a team-based approach to IC design.

To control your IC design flow you have to first document it, then have the tools that enforce your standards and conventions. Here’s a typical list of IC design data that needs to be managed across your team:

Clearly with a hardware design there are many more files and inter-relationships between the files than simple source code files.

Ad-hoc Configuration Management

Engineers are known to be self-reliant and ingenious, so why not just be careful and make multiple copies of IC design data across multiple users?

You could try this approach and have it work in small IC design projects with a few engineers however you then have to consider:

  • Who keeps track of what is golden?
  • What is the process to keep all versions updated and in synch?
  • What prevents you from over-writing the wrong files?
  • How can you go back in time to a known working state?
  • How to track versions and changes to each version?
  • Can I do an audit?

As an engineer I always preferred to be doing design work and not accounting work, so the ad-hoc approach to configuration management is not appealing.

Approaches to HCM
Two different camps have emerged in creating HCM systems:
1) Integrate with existing SCM tools
2) Single vendor approach

The first approach is tempting because the existing SCM tools might be good enough to manage all of the IC design data. Some of the limitations of integrating with SCM tools are:

  • Longer learning curve with two vendor tools instead of one
  • Increased disk size usage with SCM where each user can have a literal copy of all files
  • Keeping two vendor tools in synch versus a single vendor
  • Extending a software-centric tool to do a hardware-centric task

ClioSoft took the second approach and does not rely upon any existing SCM tool. Benefits to this unified approach are:

  • Shorter learning curve with a single vendor tool
  • Dramatically reduced disk size and network bandwidth
  • Better support from a single vendor instead of two vendors
  • Built from the ground up to be hardware-centric

Files or Objects?
A SCM is focused on files, while a HCM can raise the abstraction to objects just like an IC designer thinks about their design.

With the object-based approach shown above on the right side I can quickly see that my Schematic has four different versions and that I can click on any of the version numbers to go back in time and find out what was changed, why it was changed and who changed it.

Using an HCM in My EDA Flow
IC designers that I talk with are too busy on their current project to learn something entirely new because it simply takes up too much precious time. Fortunately they can now use an HCM that is tightly integrated inside of their favorite EDA flow:

  • Cadence Virtuoso
  • Synopsys Custom Designer
  • Mentor ICstudio, HDL Designer
  • SpringSoft Laker

The ClioSoft HCM tool is called SOS and it simply adds several menu choices to the familiar tools that you already own and use every day. Here’s Cadence Virtuoso with an extra menu called Design Manager where you typically just Check Out a cell, make your changes, then Check In. How easy was that?

Synopsys Custom Designer users also have a new menu called Design Manager:

What Just Changed in My Schematic?
One of my favorite features in the SOS demo was seeing what has changed between different versions of a schematic cell. Just click on Design Manager> Diff:

I can quickly see what has changed and what has been deleted between schematic versions of my design.


Validation engineers, design engineers and layout designers all can benefit from using an HCM system. Here’s what I learned about HCM versus SCM for IC design flows:

  • HCM is hardware-centric, while SCM is software-centric
  • ClioSoft has an HCM built from the ground up
  • HCM can be easy to learn (about an hour) and use
  • Designers spend time designing, not accounting
  • I know who is working on each part of the design, what has changed and why it changed
  • Audits are easy to do
  • Visual Diff shows me what has changed
  • HCM will help me get my IC designs done quicker, with fewer mistakes
  • ClioSoft SOS works with bug tracking tools

0 Replies to “Hardware Configuration Management and why it’s different than Software Configuration Management”

You must register or log in to view/post comments.