Cool Verification

Hi JL,

As you were the one doing the assuming, your application of the adage is half-right. 8-)

The version of VMM that we use is based on the 1800-compliant version of VMM that we released shortly after Synopsys provided their non-compliant VMM kit in open-source, and which we also upgraded to match their 1.0.1 version. The important thing for users to remember is that we haven’t modified the user’s view of the VMM library, so users can simply compile their existing VMM code against our library and it’ll work on Questa. This is actually demonstrated in one of the examples (see .../sv/examples/ovm_interop/01_islands/01_basic/). Since we released our kit, as you mention, Synopsys released VMM 1.1, and we are actively investigating this to see what, if any, updates we may need to make to the interoperability kit.

Our interoperability library provides "encapsulation" where once you've wrapped your VMM stuff sufficiently, it can present an OVM-only view to the test/testbench writer. This actually goes beyond the requirements approved by the TSC, which limits itself to the “interconnected” model where everyone needs to know both OVM and VMM. If you really want to focus on the "interconnected" model you can do that too, but we see this as a stepping-stone to the encapsulated model, which we feel is the proper long-term solution since it requires most users only to have to know about one library/use-model.

The kit actually does contain extensive HTML-based documentation which can be found in the QUESTA.html file in the top-level directory. We reviewed this documentation with the VIP-TSC and it was received quite favorably, so I think you'll find it useful. Glad to see in your update that you found it. 8-)

Now I'd like to address your detailed points:

• The layer requires use of the Mentor-customized VMM library. Thus, the ability to use the solution appears to be limited to Mentor customers. 

Not at all. The kit is released open-source and, as mentioned above, is 1800-compliant, so anyone can run it on any compliant simulator.

• The Mentor approach assumes VMM users have implemented testbenches in a standard way. For example, it assumes user callbacks have been implemented where needed in extensions of vmm_xactor. So, the layer may not be useful for running old code that doesn’t exactly follow the VMM guidelines without significant modification. 

We actually make no assumptions about how users have crafted their testbenches. Since the VMM recommends callbacks (however much I may dislike them), we thought it would be useful to show how to apply them to interoperability. But if users wish not to use callbacks, the other adapters that are provided can be used to achieve similar results.

• The decision to modify the underlying VMM library assumes users have not created extensions to VMM classes with class member names that conflict with OVM names. It also assumes users have not created their own extensions to the VMM that could conflict with the new changes. 

The underlying VMM library was modified for two reasons. As stated, the first reason was to bring it into compliance with 1800. No names were changed so no conflicts would occur. If users made their own extensions to VMM (i.e., they actually modified the underlying library code), they could make those same extensions to our compliant version.

The second reason for modifications was to facilitate interoperability, and unless users are in the habit of adding VMM extensions that begin with "ovm_" there's little chance of conflict there, too. Again, any extensions users have added, like extending vmm_env for example, would work equally well as extensions of our enhanced vmm_env.

The one exception is that we enhanced vmm_xactor to be an extension of ovm_component. Users can turn this off with a command-line switch.

• Users of the combined OVM/VMM testbench must manually customize the ovm_passthru_converter and create either a new ovm_sequence_item or vmm_data class. This seems like a lot of trouble for little benefit due to the next observation…

If you want to create OVM components that recognize vmm_data, you can do that (see .../sv/examples/ovm_interop/04_vmm_env_reuse/02_add_ovm_sb.sv). You don't necessarily have to create new data types unless (as we expect most users to do) you want to provide an OVM-only view of what's happening. In actuality, if you’re connecting an OVM component to a VMM component, they’ll each need to know about their own datatype. So, you simply define the conversion method to go from one to the other, but you don’t need to create any new datatypes. The fact that you’re starting with two components means you already (most likely) have the two datatypes anyway. This is something you have to do once, and we've discussed this many times in the TSC.

• Built-in methods and functional coverage coded in a data item class from one methodology are not available (without manual recoding) in another methodology. Given that both methodologies are written in SystemVerilog, I’d like to see some thought put into using the automation present in both the VMM and OVM to automate part of the conversion process. 

Yes, automation would be nice, but it's sometimes difficult to automate something so application specific. You have to define a mapping somewhere, and right now we just ask you do put it in the definition of the custom convert() method in the passthru_converter. Your assertion that you can't reuse built-in methods and functional coverage in data objects isn't quite as cut-and-dried either. If you want to be able to present an OVM-only view of things, then yes you have to do some amount of recoding. However, especially for coverage, the covergroup definitions actually turn out to be identical, assuming you've used the same names for your data fields on both sides. 

In the interconnected model, you can easily create an ovm_transaction or ovm_sequence_item that includes a vmm_data field and access everything via ovm_trans.vmm_data.foo. That’ll work, but now your OVM components are dependent on being connected to VMM, which isn’t what you want for a long-term solution.

• It is not possible to pass pointers to data items between methodologies. The compatibility layer assumes you always want to pass a copy. 

See previous point. Since it's all SystemVerilog, of course you can create OVM components that handle vmm_data objects. You just have to be careful and you'll probably have to rewrite things when you decide to go all the way with OVM. If you do a little judicious converting of things up front, the eventual port becomes rather painless.

I'm glad you took the time to look things over. I expect we'll have quite a bit to discuss in the TSC meetings over the coming weeks.

Tom Fitzpatrick

Verification Technologist

Mentor Graphics Corp.