Revision control for Cadence Virtuoso with git

As an EE graduate student, Cadence Virtuoso has pretty much dominated my life for the past 5 years or so. In all that time, I've never figured out a good way to backup or do revision control on my designs. So far my system has been to just tar up the whole directory whenever I feel I have made meaningful progress, but without any documentation to track what those revisions contain, it's pretty hard for them to be useful. In industry, they have professional design management tools such as Methodics, which I used briefly in an internship. Back in grad school land, the university has no desire to pay for these kinds of tools, so there's no help for this.

A few years ago, I became interested in subversion (svn) for revision control on some programming projects I had. After seeing how useful revision control was for programming, I naturally tried to apply it back on my main research focus, circuit design. The problem with svn is that it doesn't play nice with Cadence.  Cadence stores everything in subdirectories containing binary files. When you change stuff in a schematic, Cadence seems to delete everything in the subdirectory and place in new ones. This is a huge problem for svn because it likes to keep '.svn' directories in every subdirectory of a working copy. When those '.svn' directories get wiped out by Cadence, svn flips out and stops working correctly. A few years later after that disappointment, I found cdsvn, which adds a few hooks and neat stuff around svn to make it work with Cadence. It looked promising, but I just didn't want to bother with fiddling around with it and testing it to make it work. I just wanted something simple.

Enter git. I played around with it briefly before when I was interested in the whole svn vs. git vs. mercurial vs. bazaar thing, but didn't really look into it too much. After thinking about its repository structure (local centralized repository at the root directory), I thought it might be able to work with Cadence. Today, after playing around with it a bit with a test Cadence library, it seems like it might be able to do the job, at least for simple revision control.

The system as I have it worked out so far goes like this:

git init

To initialize the repository in the current directory. For a simple design, it might be easiest to do this in the library subdirectory, but for larger designs it should probably be done in the root directory holding all the libraries.

git add .

This will add all the files in the current directory and its subdirectories recursively. If you're in your root simulation directory, this will likely add a bunch of crap files you don't want, so this is most applicable if you set up a repository in a single library directory. I actually haven't played around with this enough to know how it will work if it's set up in the root directory, I'll likely provide an update on that later. Another useful thing to do is create a .gitignore file in your repository root directory and add '*.cdslck*' to it. This will cause git to ignore any '.cdslck' files that will undoubtedly be floating around in your cadence directories.

After you've played around with your design and would like to submit a revision, use:

git commit

These last two commands will pretty much be used in sequence every time you want to commit a new revision. This is so any new cells and directories that Cadence has added will also get added in the new revision. This differs from 'git commit -a', which will only re-commit modified files (not untracked files). Since I'm really only interested in basic revision control, these commands are enough to get entire library revisions tracked, saved, and documented. To look at those revisions, type:

git log

Which will give me a list of previous revisions along with their commit messages. If you ever want to take a look at a previous revision you can use:

git checkout <revision>

This works essentially like svn's revert, changing your working copy to match a previous revision. This appears to be a safer option than 'git reset --hard', which could potentially wipe out some of the repository's history. 'git checkout' when used in this way will just check out the revision in 'undetached HEAD' mode, essentially placing your current working copy in an un-named branch.  Any commits to this branch will not be saved unless you use:

git checkout -b new_branch_name

This will take all the new commits and work you've done on the un-named branch and put them on a new branch.

In my research I am usually working on designs by myself, so these commands are enough for me to implement a simple revision control system. I'm not sure how well this will work once you start introducing other people into the equation. Since all the circuit files are binary files, git features like merging don't work at all. Traditionally, design managers for circuits use a locking check-in/check-out system to handle multiple users, but as a distributed VCS, git doesn't really have a strong concept of locking.  I'm not too sure how to handle this, but it's not really a concern for me at the moment. Also, I'm not too sure how git will react once I try moving/renaming and copying libraries and cells around, but from what I've seen, it shouldn't be too much of a problem. If these issues become huge problems in the future, I think I could try and play around with the aforementioned cdsvn, which appears to be quite robust. For now though, git seems to be a simple, barebones solution for circuit design revision control.