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