What was your motivation for doing the whitepaper ?
Really there were two motivations. While the mere fact of a standardized verification language and methodology is a good thing, to misquote Churchill ( who was actually misquoting someone else ), I think it is fair to say that the UVM is the worst form of verification methodology except for all those other methodologies that have been tried from time to time. Really SystemVerilog and UVM are very clunky and frankly frustrating. It’s not that the Emperor has no clothes at all. It’s more that he has too many, and that his wardrobe is a bit faded, old fashioned and somewhat threadbare.
The other motivation was outlined in the introduction to the whitepaper. I have had a lot of fun with Ruby, Python and the latest versions of C++ recently and wanted to see how we could improve things by taking some of nice features from those language into SystemVerilog, and what effect that would have on the methodology. Once I started typing, I found I couldn’t stop, much to the bemusement of my family !
What was the reaction to the whitepaper ?
My initial worry about publishing the whitepaper was that no-one at all would be interested. However, I was really quite encouraged by the reaction. I have had a lot of positive comments and constructive criticism, as well as some healthy scepticism.
One very valuable insight that came from the feedback is that lambda syntax and closures are not exactly the same thing. Lambda syntax is just a mechanism for creating anonymous functions. Closures are a way of capturing data which is local to the anonymous function for use later when the function is called. On reflection, I think that the real gains come from the closure aspect of most anonymous function syntaxes.
A peripheral suggestion that generated a surprising amount of discussion was a suggestion for some improvements to the package syntax. This proposal was motivated by minor naming monstrosities in the UVM such as uvm_tlm_analysis_port, but I’m sure most verification engineers can cite far worse examples. The solution to this problem is some mechanism to compose small packages into larger ones, and to be able to select a component of a large package if that’s all you are using.
Another interesting discussion developed in relation to the central claim of the whitepaper, which is that complicated macros indicate an inadequate language definition. A counter argument is that the relatively primitive C like macro language of SV should be enhanced so that it would be more capable. Having seen how macro-less languages like Ruby and Python work, I still hold to the view expressed in the whitepaper, but I would be interested to understand the counter arguments in more detail.
Are you planning a follow up ?
An internal Verilab reviewer commented on the following sentence : “it is clear that there are obvious applications to callbacks, ports, etc” by saying that it wasn’t at all clear and obvious ! On LinkedIn, another reviewer said that he was “somewhat in the I’m-not-sure-this-addresses-the-fundamental-problems boat”. I can well understand these points. I felt had I to cover quite a lot of ground explaining the basic ideas, so I couldn’t really go into sufficient detail in showing how they could be applied.
Readers may or may not be interested to know that I’m working on a sequel which does go
into more detail about how to apply these techniques, in the process extending and
clarifying the ideas presented in the first paper. The intention of the sequel is to show how
these ideas can be used to create a much smaller, sleeker, and more flexible SystemVerilog
based verification methodology.
