VMM - Robust and Open, Stale and Proprietary or Somewhere In Between?
February 25, 2008
Last week I wrote an article about what appears to be an upcoming standards battle pitting the OVM vs. the VMM. My comments seem to have touched a nerve with a large number of people and prompted comments from Janick Bergeron of Synopsys, Dennis Brophy of Mentor and Ambar Sarkar of Paradigm Works, among others. Since this thread is starting to take the form of an all out smack-down, I figured perhaps the readers of this site could help me pick out appropriate avatars for Janick, Ambar, Dennis, and myself. Figured out who's who? Good, now let's continue!
Janick was concerned that my argument contained some factual errors - specifically with my assertions that:
- The VMM is not open.
- The VMM is not as feature-rich as the OVM.
Ambar commented on the need for an open reference implementation of any potential standard verification methodology library. He also bemoaned the lack of support for the SystemVerilog standard among the EDA vendors, and ended with a comment that the verification community "may not have the stamina or patience for morphing VMM/OVM into yet another methodology."
Finally, Dennis challenged Synopsys to "post their customer & partner license terms and conditions," the implication being that Synopsys uses restrictive licensing agreements with its customers.
I'd like to take some time to address Janick's concerns. Though I haven't used it myself, I believe Janick is correct that the new "VMM Environment Composition" component deals with some of the issues preventing reuse of module level verification components. It is also true that Synopsys has announced (and has released to some customers in beta form) several additional components of the VMM. The reason I didn't mention them in my original post is that for the most part, they are not currently included in shipping versions of VCS, nor are they, to my knowledge, fully documented publicly.
I stand by my original statement though about the the fact that Synopsys has "let things slide a bit recently to the point where the VMM library simply doesn't have the same robust capabilities as the OVM." Why? With the exception of the register abstraction layer, the new VMM capabilities Janick described are already part of the OVM. For example, the vmm_consensus object roughly corresponds to the objection mechanism in the OVM (look up documentation on ovm_component::global_stop_request() for more info). The flexibility provided by the vmm_subenv appears to be roughly similar to the use of an ovm_component to wrap up the reusable portions of a module level environment, but even then, it cannot match the flexibility provided by the ovm_factory object. Basically, in an environment that takes advantage of ovm_factory, a user can swap in and out different versions of objects in the environment (derived children) at runtime without requiring any changes to the underlying component. That's a powerful approach that can only be duplicated in the VMM with user-defined additions to the the library.
Speaking of user-defined additions, I'd also like to make a comment on Janick's assertion that virtual sequences have not been requested by the VMM user base. Virtual sequences are very different from the VMM scenario generator. The scenario generator (to the best of my knowledge) is used to generate transactions which are then sent to a corresponding driver. However, what is a user meant to do if the transactions need to be sent to multiple drivers and potentially contain procedural logic that cannot easily be encapsulated in a vmm_data object? I've spoken with folks from Synopsys about this, and the way I understand it, people tend to implement their own custom solutions on top of any scenario generators they may have created for their environment. That sounds suspiciously like the concept of virtual sequences to me. If I've misunderstood the purpose of the scenario generators though please let me know!
Finally, let's talk about the openness of the VMM. Let me start by saying that I'm not a lawyer and am happy to be corrected by someone who has more experience in this area than I do. As best as I can tell, Synopsys and ARM have retained full copyright to the VMM and, I'm assuming, to the API described therein. To me, that means anyone can write code that uses the API, but that recreating the underlying VMM implementation itself would require a license from ARM and Synopsys. That would mean that, contrary to Janick's assertion and separate from any discussion of whether the VMM should be open-sourced or not, the VMM is closed to development without getting a license agreement and potentially paying royalties. This brings us to the point that Dennis made about the availability of license information. I honestly have no idea what it would take for Synopsys to allow me to create my own implementation of the VMM. And, at this point, I see no value in doing so given that I could download a copy of the OVM and create derivative products without requiring a licensing deal.
As I was writing this, Adrian Coman from TrustIC (authors of a Synopsys-independent version of the VMM) and Paul Marriott of XtremeEDA chimed into the discussion. Paul makes a very good point that the VMM is not specified well enough to ensure that competing implementations all would behave in the same fashion. His other point? That the OVM is effectively a reference implementation that is complete enough to define a standard.
My question for Adrian is, do you have a license to create/sell your implementation of the VMM? If not, are you concerned that you might run into difficulties? As I said previously, I don't fully understand how other VMM implementations could be created without dealing with licensing issues.
What do the rest of you think? Is your company likely to use the OVM? To stick with or start using the VMM? Are you one of those companies (I know of a couple at least) who refuse to use vendor verification libraries unless they are open source? Are you interested in a drawn out standards battle between the VMM and OVM or are you likely to ignore the whole thing and just pick one?