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)

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!

Should I Kanban?

Recently, Bryan Morris sent me a link to his paper Yes We Kanban! That was timely, because I’ve been asking myself, should I Kanban?

I have been following an Agile Scrum approach on two projects so far, with two different employers. In both cases, I started off with physical cards on a physical board, the daily 5-minute stand up meetings in the hallway and a 2-hour long sprint planning meeting every other week (two hours is not enough time unless the backlog is groomed and pre-prioritized). On one of the projects, the backlog became too large and I started to track the cards in a spreadsheet. After about 10 sprints and hundreds of additional cards in the backlog, I had exceeded the capacity of the visual basic scripts

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?
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.

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!