Time does not exist, only matter in motion

Without the supporting mathematical proof, I postulate that time does not exist. Only matter (or energy) exists. To measure time, you need at least 3 particles: A, B and C. Particle A is our reference, let’s say it is stationary. Particle B moves along a cyclical path. One cycle around the path followed by B represents the smallest unit of time. Particle A can measure the motion of C by observing B and C. If particle B stops moving, particle A can no longer measure the motion of C: it could measure its distance, but without the cyclical movement of B, it has no way of measuring the velocity of C. If the three particles exist without motion, there is no time to be measured, because there is no cyclical motion. Time emerges from the cyclical motion of at least one particle in a universe of at least 3 particles. Is time a fundamental property of the physical world? Not according to this reasoning. That is not a reason to miss lunch however.


Chuck Norris ASIC Design and Verification Quotes

Please reply with your Chuck Norris ASIC Design/Verification Quotes.

Chuck Norris only needs a 1-bit logic vector to count to infinity.
Chuck Norris only needs one SystemVerilog construct: force.
Regressions always pass when Chuck Norris watches them.

Chuck Norris never uses the release statement.
Chuck Norris can solve conflicting constraints without rewriting them.
Chuck Norris does not use constraints, he beats variables into submission.

Send me more!

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?

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);

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

GNU Make poetry

I use GNU Make a lot. A while back I wrote this:

Three rules for a thousand Vera files
Seven for the Designers in the Valleys of Verilog
Nine for a dynamic Register Abstraction Layer
One for processing the output log
In the Compute Cloud where the CPUs lie.

One target to rule them all, One vpath to find them
One target to bring them all and in the makefile build them
In the land of GNU Make where the DAG shines.

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!