Closing Out the Conference
The Future of Specman

Mentor on AVM

Wednesday morning Tom Fitzpatrick kicked off Mentor Graphics' AVM tutorial entitled "Practical Applications of Mentor's Advanced Verification Methodology (AVM)" with an overview of Transaction Level Modeling (TLM) and the Advanced Verification Methodology (AVM) to a crowd of about 80 people.  I'd last seen Tom present info on Mentor's Questa a couple of years ago, and was interested to learn about the current status of the AVM.  The AVM is a methodology and an associated library meant for use with both SystemVerilog and SystemC.  So what is a methodology in the context of hardware verification?  According to Tom, a verification methodology should provide:

  • Automation
  • Observability
  • Controllability
  • Reusability
  • Measurability

By codifying verification best practices, Tom hopes to change the perception that "verification is an art form".  His view?  That verification is really more like "paint by numbers" and that a large portion of the work can be simplified down to a series of steps. 

I've been struggling with the implications of Tom's statement for the last several days. On the one hand, having set up testbenches and testbench shells for use by other design and verification engineers, and having used competing verification methodologies, I can believe that many parts of the verification problem can, under the right circumstances, be reduced to a series of steps. However, there is a mindset to verification that I'm not sure can ever be totally captured simply by following a series of rules. So, as with anything else in life, I would have to say that verification takes both training and a relevant set of life experiences hopefully shaped early on by a good mentor. The end result should be an ability to understand the mechanics of verifying a device, and possession of the creativity, drive, and somewhat warped mindset to enable someone to analyze a device and ask the question – over and over again – "What would happen if only someone tried…?"

Now, in all honesty, there are several competing frameworks for hardware verification methodologies, such as the VMM from Synopsys and the eRM from Cadence. What makes the AVM different? According to Tom, the AVM is different from the rest because it's…

  • Open Source – the AVM cookbook can be downloaded from Mentor's web site for free (though you need to register).
  • Based on standards such as TLM.
  • Takes full advantage of SystemVerilog through the use of assertions, the support for mixing module and classes, and the fact that assertions in modules are first class objects.

The tutorial went into detail on the different aspects of the AVM, and for the sake of brevity I won't reproduce that detail here. I'd highly recommend reading the AVM Cookbook if you're interested. If you can somehow get a hold of Tom's PowerPoint presentation, you might be even more impressed than by reading the cookbook itself. He's a self admitted PowerPoint junkie – and he's got the hard-core animations to prove it! I did want to make a few observations of the AVM. If you're not too familiar with it they might not make sense. Sorry about that.

First of all, I can't help but notice that several aspects of the AVM exist only because SystemVerilog lacks Aspect Oriented Programming (AOP) capabilities. In fact, just about everywhere that a design pattern was used (factory, observer, etc), an equivalent solution requiring much less complexity to implement could have been developed using AOP. There really shouldn't be any reason that AOP techniques can't technically be added to SystemVerilog. Given the success of that technique in 'e', it would behoove the SystemVerilog standards committee to consider adding the feature to the language. That said, the some of the hard work has been done for you within the AVM, so using it instead of developing your own solution is likely to save you a significant amount of time.

Second, if you're building a testbench using SystemVerilog, you really should be using a methodology such as the AVM. Why? Several reasons. First, using a common methodology allows you to take advantage of verification IP written specifically to work with your test environment. It also allows you to bring in additional resources to a project (new hires or consultants) and be assured that they won't have to spend time ramping up on your custom verification libraries and methodologies. I've got significant experience with the eRM, and it is always easier for me to work on an environment that is structured as I would expect. While not impossible by any stretch, having to learn a new environment takes away time that could be more productively spent learning about the more interesting details of the problem at hand – namely, how to adequately test the device under test! Finally, using a methodology like the AVM allows you to take advantage of the latest industry best practices. It takes awhile to develop your own set of internal libraries and methodologies. Then, once you've got them, you've got to continuously improve them to enable you to meet the challenges of more and more complex designs.

Finally, I'll make an observation on the differences between the AVM and the VMM. According to Tom, the AVM supports parameterized classes (like templates in C++), meaning that it doesn't need to use a "dummy callback façade" as the VMM does. If I understood Tom correctly, the AVM eschews callbacks for the most part, while it sounds like the VMM makes use of these much more heavily. I can't say that I think one way is better than the other, but it is nice that Mentor supports parameterized classes.

Tom's talk was followed by a great discussion of how to write assertions by Harry Foster. That's next on my to-do list, so stay tuned!