So which one is the best, and why?
Do we really need two different class libraries for basically the same purpose?
What about Verification IP? Which class library is best for this?

-stefan

Stefan,

This is a loaded question and one that can be debated from many different angles. I will attempt to adress this from a very high level. Both AVM and VMM adress the same issues and are both aimed at easing the life of the verification engineer. I think that we will begin to see a large concentration on verification methodology in the near future from all major EDA vendors, and minor ones too. One of the main reasons for this is that the SystemVerilog language brings with it some 200+ new constructs, many of which are verification-centric. While SystemVerilog is a common, standard language for both design and verification, the new features added to the language are sufficiently complex that any canned methodology that will assist new users in achieving productivity gains more quickly is a welcome addition. Whether it be AVM, VMM, uRM or any other methodology that may emerge, a solid methodology and the use of a standard language are key ingredients in any good recipe for verification success.

To integrate verification IP from many sources, a common implementation methodology always makes life much easier. While the EDA industry has not converged on a single methodology yet, my hope is that in the long term, one clear winner will prevail.

Corey Goss
Manager of Education and Training
XtremeEDA
ASIC Professional Services
www.xtreme-eda.com

A very diplomatic answer :)

From what I've seen so far it seems like VMM suffers from its RVM legacy and doesn't use the full
potential of SystemVerilog, while AVM is still somewhat immature and less proven in real projects.
But as I only have hands on experience with RVM and VMM I really don't have the full picture.

-stefan

Stefan,

May I also suggest our free and open source framework? It's at trusster.com and runs on both MTI and Synopsys, right now. We also have a C++ version.

Take Care,
mike@trusster.com

Stefan,
Can you elaborate a little on the RVM legacy comment? I've seen AVM in slides/PDFs and VMM in action for several months now (and have coauthored a book on VMM adoption, see www.systemverilog.us). One thing I do see lacking in VMM is it doesn't use parameterized class usage, I'm not a big time C++ user so I perhaps don't realize what I miss by not having it. Otherwise I see VMM as very capable and modern. For instance its atomic and scenario generators are far superior to those in AVM - AVM has a avm_stimulus (2.0 version, didn't check 2.1 yet) which is not as mature as it can be IMHO.

With recent AVM changes to 2.1 I see that it is still evolving and that's good for all of us. AVM enjoys good interest as anyone can freely download it and try out. But AFAIK AVM doesn't run outside Questa due to lack of construct support. VMM atleast we hear of running in both simulators (See www.trutic.ro).

I would really like the TRUSS way, I'm little tied for time else I will go all out and try that fully. From the marketing point of view, I see it has all the potential to become the "Linux of Verification" (Mike - reuse of your words :-) ). But I'm yet to see its technical strengths against VMM/AVM.

Also for VMM, there is an opensource initiative at www.vmmuser.org If we get enough support from engineers we can make VMM book as a LRM and several implementations such as one by Synopsys, one by TrustIC, one as OpenSource etc. But for that I believe VMM gurus should be open minded to accept good things from the likes of AVM, Truss - not sure if that will ever happen :-)

Regards
Ajeetha, CVC
www.noveldv.com

Regarding the RVM legacy in VMM, the most obvious is as you mentioned the extensive use of macros instead of parameterized classes, but there are also several examples of other strange features that look a bit like "temporary fixes gone permanent". The most striking example is the vmm_channel class.
It can be a FIFO, but does also support random access.
Not very clean as the communication channel semantics are determined by the transactors attaching to it instead of the channel itself. It has a "tee mode" that adds an extra evsdropping port, to which one, and only one transactor may attach. Odd.

There are also quite a few places where you need to do things by hand when the library could have done it for you. E.g:

vmm_data::psdisplay - why do I have to add the prefix string to each line? This should be done automatically.

Why do all transactors that have been created in vmm_env::build have to be started explicitly in vmm_env::start and stopped explicitly in vmm_env::stop?

The tedious testing for null parameters in transcator constructors:

if (p == null) this.p = new(...) else this.p = p;

Why do I have to implement the vmm_data::copy method even when its implementation is obvious?
(though this probably is a limitation in SystemVerilog itself)

etc.

regards,
-stefan

I think you need to clearly state whether you are referring to Synopsys VMM or a second party vendor developer of VMM. The "stock" Synopsys VMM does NOT run on any simulator but vcs. The licensing agreement in order to get the source code of the SNPS VMM limits its use to your organization only.

Back to the original question, which is best? That is a truly subjective item. I would say that currently it mainly depends on what platform you are using in your organization. If you are a vcs only site, then VMM would probably be a better choice, unless you have the resources to modify the AVM library to work on your vcs or nvc platform. If you are an mti user, then AVM is the only way for you since you would not be allowed access to VMM source code. However, if you have significant resources to modify source code then the current licensing model of the AVM has some advantages.

They are all providing the user with comparable mechanism to gain productivity while enforcing some coding guidelines, which most organizations can certainly use. They just offer it in subtly different ways of implementation.

One big problem is when you must develop test bench code that needs to be able to be ported across all 3 vendors and you get VIP that is developed against different libraries. This now makes the work very hard since the level SV implementation varies so greatly from simulator to simulator.

As "dont" write, the main issue is really portability and interoperability.
I hate proprietary solutions, and today both VMM and AVM are in practice proprietary as they won't run on more than one simulator (unless the TrustIC stuff can be trusted in the long run).

One single standard is obviously what is needed. Preferably one that is not controlled by one single tool vendor. But what are the odds for that?

-stefan

If you have the source code to your favorite methodology's class-library, then you're free to run it on whatever simulator you like (subject to the simulator supporting sufficient SystemVerilog and the license restrictions on said class-library's source). The only standard that's really relevant, surely, is P1800. As long as you have free access to all your source, you can't claim to be locked-in. One must not forget that, in the case of the AVM, the source is also available in SystemC - so effectively you don't need any proprietary simulator at all. If I understand correctly, the AVM source is available under an Apache license, which grants most of the freedoms required (IANAL though).

At the end of the day, the real IP isn't in the verification framework, it's in the detailed guts of the implementations of all the protocol and design specific "stuff" that makes up the bulk of the effort in putting together a verification environment. One can view methodology as scaffolding, it helps hold things together, but you still are required to do a lot of building to make something useful.

Paul.

Hi,

This is a great thread. Please consider downloading and taking a look at teal and truss (trusster.com). It runs on Modsim and Synopsys today. Teal is a set of methodology independent utilities and Truss is a VMM/AVM-like framework.

One main difference between truss and the VMM/AVM is that Truss does not get into the transactor, BFM, or data base class business. I feel very strongly that this is the right approach. Of course, I have my preferences and style, but it is not appropriate for base classes and tons of rules.

Take Care,
mike