How to tape out ASICs like they’re software releases

ASICs are massive software projects. Millions of lines of design code, and millions of lines of QA code to make sure you are not taping out a coaster. Due to the high fabrication cost, ASICs tend to be released infrequently, as it makes economic sense to cram as many features as possible into a single release. The fabrication cost of providing N features is almost the same a providing N+M features, given the same geometry. So the more features you cram in there, the lower your cost per feature.

Except one thing: people. Past a certain size, the project is too big. It’s too big for people to fit all the features in their mind. Too many features to track at the same time, too many interactions between features, too many implications… the schedule slips. And slips again. And again. So the business decision is: tape out now, right now. And your answer is: we can’t, the HEAD of the database has all these features, under development, and at the same time we’re debugging them, and some files won’t even compile, we can’t tape out, we need to freeze the feature set, stabilize the code, run regressions for two months and bug fix as much as we can before we freeze RTL, then maybe fix a few dozen bugs in ECOs.

Everyone knows it sucks to do bug fixes in ECOs because it’s way harder than in RTL. It’s like bug fixing machine code, then porting the fix back to the source, without being allowed to run the compiler on the source code anymore!

But I digress, the question is, how should source code be managed to maintain it in a state where tape out opportunities are the norm rather than the exception? You obviously can’t allow chaotic commits to the source code database, much less chaotic commits to the release branch! Let’s examine those the source code management strategies used in software and try to see how they fit the ASIC development world.

The single branch broken trunk model: all the commits, design and verification, go to the same unique branch, stability is declared at certain points when enough simulations have managed to pass and designers happen to have been quiet on the feature front. Most times, the HEAD of the database is just broken.

This is possibly the easiest model to follow for people who cannot afford to learn how to use branches. However, the head being broken most of the time means that tape out dates are somewhat unpredictable as a period of stability, on an unknown committed feature set, is required for integration and bug fixes. This period of stability also impacts all future code development: since there is only one place for code to go, new development cannot be committed after RTL freeze.

In this model, the only way to allow new development after RTL freeze is to open a second database, and copy and paste all the code and the bug fixes over to the new database.

Pros: easy; no source code management learning curve
Cons: tape out dates are unpredictable; new code breaks working code all the time; continuing development after the RTL freeze is not possible

Broken trunk, tape out branch model
In this model, a branch is created in the database for each tape out tentative. Since it takes a few days to a few weeks before the code for tape out is known to be good for tape out, isolating tape out from the main development trunk is wise: development can continue and will not break the tape out code. Usually, only bug fixes are allowed on the tape out branch. A tape out branch can be abandoned when a better feature set is available on the trunk where a new tentative tape out branch can be created.

The ease with which these branches can be created and maintained heavily depends on the source code management software being used. CVS being one of the oldest SCM around is also the most primitive in terms of branch support. Support for branches is much more developed in git as repeated merges are supported, among other great features.

Pros: tape out and re-spins are isolated from development; back end team can control what goes into the tape out code without locking down the whole database
Cons: the development trunk is broken; a stability period is still required but it can be moved to the tape out branch while development continues on the trunk; back end engineers must learn how to use branches

Stable trunk, tape out branch model
In this model, developers are not allowed to commit directly to the trunk unless their code has passed some tests proving that it won’t have adverse effects on the rest of the code. The typical steps for this model are branch, edit, commit, test and merge. When the tests are successful, designers are allowed to merge the changes to the trunk. Changes to the tape out branches is done the same way.

Pros: the trunk is stable, tape out dates are more predictable as there is no stabilization period on the trunk; cowboy coders do not bring everyone down when they commit unstable code
Cons: stabilization happens on the branches, along with feature development; everyone must learn how to manage branches

It does not take long once you have branches in your methodology to realize that you want to merge to and from the stable trunk, since a feature branch may want to integrate a feature from the trunk which was not available at the time the branch was created. Fortunately, this kind of development is made easy by new decentralized source code management software such as git.

As a bonus, decentralized SCMs allow you to share code with others without releasing it to a central database, reducing the number of branches or tags visible to others.