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.

Verif star

Way back, in another place and in another time, our back end guru referred to verification engineers as “verif star”. But he explained it wasn’t a compliment: he swiftly moved his finger in the air to indicate the star he was referring to was “*”, as in “verif*”, the regular expression meaning “all of you who verify this chip”. We all thought this was much cooler than being called DV Engineers, or Verification Engineer, so we adopted this as our official job title: verif*

Seen by software developers as “the people who make sure the NAND gates are working”, and seen by the ASIC designers as “the people who share their files with other people”, we are the verif*.

In any case, this post has been sitting in my “Draft” folder since 2008, it is time I get it out before someone else does.

Gradle Q&A for myself

Q: Gradle task does not show all the tasks, why?

A: By default gradle hides tasks that:

  • Do not have a group
  • And are a dependency of another tasks, because gradle assumes you would not be calling this task from the command line

Things I learned in the book Gradle beyond the basics

Help me improve this document!


Tasks can be created by rules. These tasks are called “task rules”. They are dynamically created when a task matching their pattern is invoked.


Single project build phase

Initialization phase

  1. Execute settings.gradle
  2. Determine whether it’s a single project or a multi-project
  3. Locate the build files
  4. Create a Project object

Configuration phase

  1. Load the Project object
  2. Execute gradle.projectsLoaded()
  3. Execute project.beforeEvaluate()
  4. Execute the build file as groovy scripts, against the Project object
    1. DAG gets created
    2. Hook methods are run
  5. Execute project.afterEvaluate()
  6. Execute gradle.projectsEvaluated()

Execution phase

  1. Identifies the tasks to run
  2. Execute the tasks marked for execution
  3. Execute gradle.buildFinished()

Multi-project build phase

I am guessing that this puts a couple of  loops in the configuration phase and in the execution phase…

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!

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 Read more of this post

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