Last week I attended the Design and Verification Conference in San Jose. It had been six years since my last visit to the conference. Before then, I had attended five years in a row, so it was interesting to see what had changed in the industry. I focused on test bench topics, so this blog records my impressions in that area.
First, my favorite paper was “Lies, Damned Lies, and Coverage” by Mark Litterick of Verilab, which won an Honorable Mention in the Best Paper category. Mark explained common shortcomings of coverage models implemented as SystemVerilog covergroups. For example, because a covergroup has its own sampling event, that may or may not be appropriate for the design. If you sample when a value change does not matter for the design, the covergroup has counted a value as covered when in fact it really isn’t. In the slides, Mark’s descriptions of common errors were pithy and, like any good observation, obvious only in retrospect. More interestingly, he proposed correlating coverage events via the UCIS (Unified Coverage Interoperability Standard) to verify that they have the expected relationships. For example, a particular covergroup bin count might be expected to be the same as the pass count of some cover property (in SystemVerilog Assertions) somewhere else, or perhaps as much as some block count in code coverage. It struck me that some aspects of this must be verifiable using formal analysis. You can read the entire paper here and see the presentation slides here.
I was also impressed by the use of the C language in verification — not SystemC, but old-fashioned C itself. Harry Foster of Mentor Graphics shared some results of his Verification Survey, and there were only two languages whose use had increased from year-to-year: SystemVerilog and C. For example, there was a Cypress paper by David Crutchfield et al where configuration files were processed in C. Why is this, I wondered? Perhaps because SystemVerilog makes it easy via the Direct Programming Interface (DPI): you can call SystemVerilog functions from C and vice-versa. Also, a lot of people know C. I imagine if there were a Python DPI or Perl DPI, people would use those a lot as well!
Of course, the Universal Verification Methodology (UVM) is becoming, well… almost universal. I get the impression that verification architects are turning into software engineers. They are having fun, if that is the word, creating abstractions so that they can re-use the same top-level verification code in different circumstances, with differing design blocks or versions of IP. But like creating classes in C++ software, as I do for Real Intent, there are many different ways of doing the same thing. It seems to me UVM has made the verification problem less constrained rather than more constrained, in some sense, and that does add some risks, as well as make static analysis more difficult.
The crowd got a kick out of the fact that even the UVM experts can’t agree among themselves how much of it is minimally necessary; there were some lively discussions among the presenters in the UVM Session on Wednesday afternoon. First, Stu Sutherland and Tom Fitzpatrick proposed a minimal subset. The next two authors contradicted it. One feature that Tom said never to use was then the subject of a paper by John Aynsley. Last in the session, my friend Rich Edelman described his UVM template generator. I think there could be as many template generators as authors!
Some presentations had the tinge of an advertisement. There was an “e” paper where a user described reasons to miss aspect-oriented programming, which is not found in SystemVerilog. For the first time, I got a good definition of aspect-oriented programming, which you will find on Wikipedia, as focused on cross-cutting concerns. My paraphrase of cross-cutting concerns is a feature that usually requires implementation in multiple locations; an aspect-oriented language can put the cross-cutting concerns in one place. But it also strikes me that an aspect-oriented language really allows the extension or re-definition of anything from anywhere. This may in fact be aspect-oriented, or it may not; nothing guarantees that it is. If not, you risk a giant mess where you need to read all the source code to understand anything. At least, object-oriented languages like SystemVerilog have features that push people in an object-oriented direction.
Finally, for Real Intent, I was encouraged to hear from Harry Foster, during the “Art or Science?” panel, that “formal apps” — or focused formal applications dedicated to analysis of a particular problem area — grew in usage year-to-year by over 60%, and this is the fastest-growing area for EDA tools. I’m glad to be working for a company in such an interesting area.
P.S. The answer, by the way, to the question of whether verification is “Art or Science” is easy. Of course, it’s both!