Why ASIC designers should not fear merging or conflicts

ASIC designers have a very strong sense of ownership towards their code, and although they collaborate at interfaces, they seldom let another designer edit their code. I finally understood using an analogy.

ASIC designers are like civil engineers. Let’s look at what each type of engineer builds:

Civil Engineer ASIC Designer Verification Engineer
City blocks ASIC blocks Data Generators
Highways, Roads Buses, Signals Transaction data
Intersections, Traffic Control Devices Muxes, Arbiters Functions and methods
Buildings Memories Abstract data types, lists, databases

The things ASIC designers (and civil engineers) build are static in nature, they don’t flow, they don’t live: they exist to hold stuff and do things to stuff. Their creations are instantiated statically, and while they can serve more than one need, they are the place you go to for a service. The file that describes the “road” or the “building” is strongly tied to the engineer who designed it. And so designers see nothing limiting in operating a versioning control system that locks files while they are being edited. And when two people edit the same file, panic sets in: how can a file be edited by two people at the same time? How is this not breaking the file (and ruining my design)?

The verification engineer on the other hand builds the living things that flows through the services provided by the statically instantiated hardware. Those living things travel on buses, flow from block to block, get stored and are read back to be stored in another place. They are processed by multiple hardware instances. They are transformed along the way. They don’t have a sense of ownership over the data they throw at the design.

The problem of merging and conflict resolution has been solved a long time ago. Have no fear. But I guess it depends on the tools you are using.

This post was originally written in 2008, but has been published in 2016!

Verilog exit code for simulation status

In wrote this post in 2008. We are in 2016, and I decided to publish it,. since one of my favorite bug has been fixed.

Until recently, Verilog could not pass an exit code to the parent process when it ends. The $finish function can accept one argument, but it is for printing simulation time, statistics and CPU time to the screen.

To quote the release notes:

Starting with the K-2015-09 release, simulation executable generated by VCS returns a non-zero value in case of fatals, errors and assertion failures.

Look up the -exit and -exitstatus options in the manual.

Verilog turns 30 this year!

Venerable Verilog turns 30 this year, and here is my very short list of things that I wish were not stuck in the 80’s!

  1. Verilog cannot return a user defined exit status like normal programming languages (e.g. sys.exit(1))
  2. Verilog does not give to the users access to raw command line argument values (e.g. argv)
  3. Verilog does not have a singly rooted hierarchy (proof that it’s needed: VMM and UVM had to create a base class from which everything else inherits)
  4. Verilog modules do not have conditional IO ports (like a generate statement to select IO ports, or parametrized IO ports)
  5. Manifest files are relative to the current working directory of the compiler, making life miserable if you attempt to write portable manifest files to be used in other projects.
  6. Include files are relative to the current working directory of the compiler, making life miserable if you attempt to write portable source (SystemVerilog LRM 22.4). This dates from the early days of the C compiler doing the same, but C now supports relative paths in #include directive. Verilog never caught up.
  7. Verilog has no way of reporting low level errors in the chain of context where they occur (e.g. throwing an exception up the call stack to report it in its context).

On the other hand, Verilog has evolved quite a bit in a lot of critical areas to design and verification, and I will not list them here as they are all over the internet, and there are excellent books out there (I really liked SystemVerilog for Verification by Chris Spear).

Verilog is a unique language, in the sense that when a problem that cannot be solved presents itself, Verilog gains new keywords and sometimes new syntax, while other programming languages gain a new library, or gain the ability to solve the problem (e.g. generics in Java). This makes Verilog, fascinating and complicated at the same time, with 250 keywords to memorize (and 73 built-in system functions)!

Before purists correct me, yes I know, I am lumping Verilog and SystemVerilog in the same boat here, forgive me!

Name your compare method diff

In this article, I will talk about naming the comparison method “diff”, what constitute a good return value for the diff method, and how I emulate exception handling in SystemVerilog, a language which does not have formal exception handling.

First, we name the comparison method diff rather than compare. Why? Because is it easier. Consider this code

if (packet1.compare(packet2)) begin
  // what does compare return exactly?
end

Chances are that you have to look up the compare method to see what it returns before you write your code, each time. Now read this code:

if (packet1.diff(packet2)) begin
  // it reads like english
  // so packet1 must be different than packet2
  $display("Packets are different);
end

Much easier. And I bet you don’t have to look up the diff method. Read more of this post

Git push for is publishing, not for integration

This may seem obvious, but don’t use git push like CVS commit. Repositories should be accepting commits by pulling them, not pushing them. CVS commit may be your integration strategy in a simple world without branches, but git push shouldn’t be used for that.

In the land of ASIC development, where a CVS commit is instantly shared with all the ASIC designers, the worst that can happen is someone unintentionally commits a file on a branch. Then what? You go talk to the verification guy (why do they do always know how to fix CVS?) and admit your mistake. He fixes it and everyone gets the fixed up repo on their next update, no biggie. Not so much with git.

With git, as soon as you have pushed the commits, the central repository branch on which you just pushed looks exactly like the local repository branch it was pushed from, with the commits you wish you had done on another branch, and the commits you should have reverted before continuing, but more devastatingly, with the incorrect merge you should not have done. Sure, git gives you the ability to correct all your mistakes IN YOUR LOCAL REPO, but once you’ve pushed them to the central repository, it’s like a printed newspaper: it’s out there and there is no recall, only further editions. Actually, you can fix an incorrect merge, but wouldn’t you want to avoid them in the first place?

So instead of having developers push to the integration repository, the integration manager should obtain the code through a git pull. If the integration tests pass, the commits are then pulled into the release repository by the release manager, where everyone can pull from. If the tests fail, the commits are taken out of the integration repository (where no one can pull from), the contributor is notified, and the integration manager processes the next integration request.

All this may seem obvious, but today when an incorrect merge between two branches was pushed, effectively merging the branches on the release repository, it became clear to me that the workflow needed to prevent this from happening, and that it could be done easily if two conditions were met:

  1. use git pull for getting code into a git repository
  2. use two repositories, one for integration, and another one for releases, thereby isolating the release tree from mistakes on the integration tree

You could argue that development, integration and release can all happen on different branches of the same repository, but in reality, typing git merge followed by git push is and easy mistake to make (never trust humans), whereas a CI system pulling code will not inadvertently merge two branches.

Wait, I have just found git bundle… more ways to skin the cat!

Git Workflow for ASIC Development

Pro GitI recently purchased Pro Git at my local Chapters bookstore. After reading it, I discovered I could get it for free on-line, but that did not make me feel bad, on the contrary! In a week, I had taken it everywhere, and showed it to half a dozen people.

The reason I blog about this book is because in reading chapter 5, I fell in love with the Integration Manager Workflow as I think it could completely replace the CVS workflow I previously described on AgileSOC.

The Integration Manager Workflow works as follow:

  1. A central blessed repository holds the tape out version of the ASIC database.
  2. Each ASIC developer pulls from the blessed repository to develop new features and implement bug fixes.
  3. Each ASIC developer publishes their changes to their “developer public” repositories.
  4. Through an automated process (partly provided by git built-in commands), they request that their changes be pulled in into the integration manager repository.
  5. The integration manager queues the requests, and if they pass the tests, they are accepted and committed into the blessed repository.
  6. Rinse and repeat.

Here is a picture from the book representing the Integration Manager Workflow, reproduced here thanks to the Creative Commons Attribution-Non Commercial-Share Alike 3.0 license:
Integration manager workflow

But that is not all. I discovered GitHub’s network graphs (the link takes you to an article linking to a live clickable network graph). If you’ve ever wondered what the hell designers were up to in your ASIC team, GitHub’s network graphs is the answer. The network graphs show you what happens live in your Integration Manager Workflow. It shows commits across the multiple databases (repositories), as well as the merges into the integration repository, from any developer’s point of view. This most impressive hosting solution can be purchased and installed inside your intranet.

I am currently installing gitolite to manage access to the repositories. Hopefully, that will go well!

This blog entry is published under the terms of the Creative Commons Attribution-Non Commercial-Share Alike 3.0 license because it uses work published under this license.

A Continuous Integration System For ASIC Development

I recently wrote an article published on AgileSOC titled
A Continuous Integration System For ASIC Development.

Hope you enjoy it!