Mentor Responds: OVM/VMM Compatibility Layer
DVCon Misfits Unite!

More Thoughts: Mentor OVM/VMM Compatibility Layer

Last week I wrote a post about the Mentor OVM/VMM compatibility layer, and subsequently posted a response to that post from Tom Fitzpatrick.  Now, it’s my turn to respond.  Tom made several points that I want to address.

First, I claimed that the Mentor solution was likely to work only on Questa.  In response, Tom said:

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.

I think by now it is well known that the three major simulators do not yet support the same portions of the SystemVerilog standard.  Therefore, it is likely that the Mentor code may have issues running without modification or `define workarounds on VCS or IUS.  This is true in the OVM library itself.  Disclaimer: I have not tried running the compatibility layer on either IUS or VCS.  Of course, if I did and then reported the results my understanding is that I’d likely be contacted by lawyers from one or more of the EDA vendors involved.

Next, Tom said this:

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.

That presumes it’s actually possible to merge the changes in, and also that end users actually want to go to the trouble to do this.  Additionally, Tom commented on my assertion that changing the VMM library could cause name collisions with existing code.

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.

After browsing through the Mentor docs, the new methods added to the VMM do not appear to use an “ovm_” prefix. Here are some examples from classes other than vmm_xactor:

  • post_inst_gen in vmm_atomic_gen
  • vmm_env::run_step
  • vmm_channel::peek1

Regardless, the vmm_xactor exception is exactly what I was referring to, so my original point (that the OVM extensions to the VMM could cause namespace collisions with existing code) is still valid.  Based on the documentation, turning off the vmm_xactor modifications causes the user to have to write some additional code in the OVM wrapper and allows the vmm_xactor to be started without a vmm_env.  The first feature (reducing code required to instantiate the xactor) seems minor but the second (starting the xactor without an env) seems potentially more of an issue.  Someone from Mentor care to comment?

Moving on, in my original post, I said:

  • 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…
  • 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.

In response, Tom described a couple of possible ways users might want to handle data types, which I’ve summarized below:

  • You have two similar, pre-existing data types – one in the VMM and one in the OVM
  • You have a VMM data type and need to create an equivalent in the OVM, or vice versa

I believe it would be unlikely a user would have an existing data type in both methodologies.  More likely is that you have one but not the other.  You could create an ovm_component that handles vmm_data objects, as Tom suggests, but that could involve a lot of manual coding.

One of Tom’s main points is that there will be some manual recoding required because each user data type is different.  My point is that the things that are common between the OVM and the VMM, such as copy, compare, print, etc should be automated.  The user-specific functions could likely be called directly regardless of the methodology being used.  I spoke with a SystemVerilog user the other day whose company has dictated a switch from one base class library (BCL, such as OVM or VMM) to another.  He mentioned that without the ability to easily reuse built-in functions a compatibility solution would be useless.  I’m not sure a solution would be totally useless, but it would certainly be less useful.

Tom mentioned that covergroups would remain the same between the OVM and VMM versions of the data objects.  That implies you need to have two copies of the code which sucks because you need to maintain both.  Unless, of course, your goal is to move permanently from the VMM to the OVM.  That’s probably the key observation to make here: The Mentor proposal is really a proposal to help companies convert from the VMM to the OVM, not continue to use both in perpetuity.

I look forward to hearing back from Tom and others on my analysis.  Anyone else have strong opinions about this topic one way or the other?  Do you even care about interoperability at all?  Whichever way you're leaning, please let me know!

Comments