Mentor OVM/VMM Compatibility Layer
January 15, 2009
Update 1/16/2009: Found the Mentor docs for the interop solution (thanks to Tom Fitzpatrick from Mentor) - fixed appropriate comments below.
Last month Mentor and Cadence each released separate versions of compatibility layers to allow VMM code to interoperate with OVM code on their respective simulators. I’ve spent some time over the last couple of days reviewing the Mentor solution and wanted to share my initial thoughts.
The Mentor solution uses a customized version of VMM 1.0.1. Unfortunately for Mentor and Cadence, Synopsys released a new version of the VMM, 1.1, a couple of weeks later which contains changes in stimulus generation capabilities (among other things) that might impact the way the compatibility solution is architected. I will be interested to see how Mentor modifies their solution to take the changes into account.
In addition to a modified version of the VMM, Mentor uses a library of compatibility widgets to deal with the following aspects of OVM/VMM interoperability (with examples of associated new classes):
- Shuttle data back and forth across library boundaries
- ovm_passthru_converter
- vmm_converter_channel
- vmm_channel_adapter
- Coordinate simulation phasing
- ovm_vmm_env_wrapper
- Allow interaction between VMM and OVM stimulus
- vmm_generator_adapter
- vmm_scenario_gen_adapter
- vmm_scenario_sequence
- vmm_driver_adapter
Documentation on the compatibility layer is difficult to come by and can be found by viewing the Questa.html file in the Mentor tarball. I missed the Accellera call where Mentor presented the solution, and based this analysis on the WebEx sent out by Mentor and the code itself. Mentor sent out a link to a WebEx to Questa Vanguard partners with additional info about how it works. The following observations are based on a review of that presentation and of the code itself:
- The layer requires use of the Mentor-customized VMM library. Thus, the ability to use the solution appears to be limited to Mentor customers.
- 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.
- 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.
- 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.
- It is not possible to pass pointers to data items between methodologies. The compatibility layer assumes you always want to pass a copy.
As I was writing this I was reminded of that old adage - “When you assume you make an ass out of u and me". However, I think Mentor has done a good job coming up with a first-pass solution to the interoperability problem. It is much easier to talk about what a solution should look like when you’ve got a working example (or two) to play around with. I’m looking forward to hearing feedback from others on the Mentor approach.