Git is a distributed version control system that operates on the principle of storing all history while providing high-level operations. Git is perfect for software design because it allows you to maintain an entire project in one repository, but the same can’t be said for hardware design.

Software has become more complex requiring more iterations, files, and engineers spread across more time zones. Software tools to manage this large amount of data have evolved to meet these challenges. The original version control tools like RCS and SCCS managed revisions of files but did not address managing collections of files that make up a software project. Wrappers like CVS were developed to address this need. Client-server systems such as Clearcase, Perforce, and SVN were needed to handle multi-site development and software configuration management. Finally, Git and Mercurial evolved to handle the truly distributed development of large open source projects. 

The problem of configuration management is not unique to software development. Any type of development that involves many iterations of a large collection of files with multiple contributors has to deal with the same problems. Semiconductor or mechanical designers, game developers, architects, etc. all have to accurately track revisions and configurations of a large set of typically large files. 

Over time, Git has arguably become the de-facto standard for revision control and configuration management of software but is Git ideal, not just workable, for managing projects in other domains and workflows? This blog post explores the suitability of Git for managing semiconductor chip design as a way to try and answer this question.

How is semiconductor design different?

IC design, just like a software project, consists of a large number of files with several engineers creating multiple iterations as they develop, debug and refine the product. Of course, they need to effectively and accurately share their changes with team members. Releases, patches and variants may have to be created as the project progresses.

Besides these core similarities there are some distinct differences:

• Digital designs are typically done using text files written in an RTL language, such as Verilog, using text editors. However, there are other analog, custom, and packaging components that are created using specialized graphical editors such as schematic and layout editors.
• These graphical editors often create a collection of related files that often include large binary files to represent each design object.
• A software workflow essentially consists of a loop of edit, compile & debug where the compile step may sometimes not be needed. A semiconductor design flow is much more complex. There are multiple different editors to create the design components. Multiple steps such as synthesis, place & route, simulations, formal verification, timing analysis, etc. are needed to complete the design. These tools require engineers with different expertise and produce large and often binary files that sometimes need to be version controlled.
• Some components may be reusable in whole or in part, typically referred to as Intellectual Property (IP) blocks. Often, IPs may be purchased from third-party vendors.   

Git is a powerful tool that works very well for managing software development, with each engineer working on developing a feature or fixing issues. Its powerful ability to merge changes to text files enables truly efficient distributed development, especially for open source projects.

Does GIT meet the requirements of semiconductor design?

However, it does fall short in meeting the unique requirements of a semiconductor development environment, especially in a corporate environment. Let’s explore what these unique requirements are and where Git falls short:

• IC design often has several very large files from 100s of MBs to several GBs. The Git working model, where users create a clone of the repository, means that every user is creating a copy of all the large files but also all the revisions of these large files. This can be very cost-prohibitive in a corporate environment where most design data is stored on expensive high availability network storage. 
• IC design, particularly analog and custom, generate binary files. Since merging of schematics and layouts cannot be automated, it works best to have a centralized repository with edit locks to avoid difficult and error-prone manual merging.
• A design object is not created in isolation by one engineer. It involves multiple engineers, such as design engineers, verification engineers, layout or place & route engineers, to name a just few. The engineers have to be in close synchrony and cannot work in isolated silos. A centralized repository helps engineers synchronize their work more frequently and improves collaborations by allowing engineers to see who is working on what and keep abreast of changes. 
• Design teams are often geographically distributed. Sometimes the design engineers may be in one site and the layout engineers across the globe. The team members need to synchronize their changes daily or more frequently. Technology such as cache servers would be needed to make this efficient especially given the size of the design data.
• Design objects are often stored as a collection of co-managed files. A configuration management system should ideally recognize these as related and manage it as a single, user recognizable, composite design unit, and not just files with program-generated names. Since different engineers have different types of expertise, it is often necessary to put access controls in place. For instance, you may want to make sure that a layout engineer doesn’t accidentally modify a schematic or vice versa. You may also want to prevent contractors from having any access to sensitive libraries. To enforce access controls, you need to have project data managed by a centralized server.
• While data may be stored in a flat directory structure, IC design is typically a hierarchy of blocks with each level of the hierarchy instantiating a lower-level block. An IC designer would need the configuration management system to extract and operate on a design hierarchy.
• Imagine how painful it would be if software developers were not able to compare versions of files to identify what has changed. It would be very difficult to review changes or try to find what change caused the new bug. Shouldn’t designers and layout engineers expect to have the tools to find differences between versions of schematics or layouts?
• Of course, the most important requirement of all is that revision control and configuration management features are seamlessly integrated into the design tools the engineers are using. Not only is this a matter of convenience, but the design tools have to be aware of the configuration management system to make sure that adds, deletes, and changes are correctly recorded.

Conclusion

The temptation is to look for tools that already exist and shoehorn them to meet similar needs in a different domain. Git and other software configuration management (SCM) tools, as the name suggests, were developed by software engineers to meet the needs of software engineers. Each domain may have some unique requirements that are different from that of software development. It makes sense to explore the requirements of your development tools and methodology before adopting a configuration management system that you will work with for many years. Git-r-done or Git-r-don’t? That is the question!