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

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

Builds

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)

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