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.