OVM - The Methodology for Enabling an Industry-wide VIP Eco-System

Anonymous — Sat, 16 Aug 2008 15:45:38 GMT

Harry, You are right that there are many areas where VMM and OVM are incompatible. Beyond the items you mention, there are many other incompatibilities like controlling and coordinating stimulus across multiple interfaces, controlling and printing out debug messages, verification component architecture, DUT error messages, etc... As I mention above, I also believe that VMM did not do enough to enable full reuse even between different VMM users - it definitely went a long way from having no methodology, but it currently does not support the same level of reuse that OVM/eRM customers have experienced over the years. The point I am trying to make in my blog is that if you want to get to the next level of reuse, you should move to OVM vs. making your own custom extensions to VMM since you will need to change anyway in order to get better VIP reuse and leverage VIP from the larger Industry VIP ecosystem. Since there are customers who have used various aspects of VMM, we now have a way to run code that on the Incisive Simulator, and with AE help we now have a path for these customers to migrate to OVM. I never claimed we solved all of the VMM/OVM incompatibilities.

mstellfox — Sat, 16 Aug 2008 15:15:04 GMT

JL, this illustrates one of the key points that I am trying to make - yes, VMM shows an "optional" way a user might try to mimic virtual sequences, but with OVM we provide a _standard_ way for modeling stimulus so that every testbench developer will use the same approach. This is key for enabling real plug & play reuse. If one user models stimulus one way, and another user models stimulus another way, it is cumbersome to reuse the VIP between the different users. Whereas with OVM sequences, we are prescribing one way to model stimulus so that regardless of where I get my OVM VIP, it will always have the same kind of stimulus interface. In addition, OVM sequences have much more power and flexibility compared to VMM scenarios - for example, late generation to enable reacting to DUT state, unlimited layering as opposed to just two layers of stimulus in VMM to support things like high level protocol layering (like PCI-Express having 3 protocol layers), less setup for the user to use sequences, no need to use explicit paths to the stimulus generators which inhibits module to system reuse - to name a few...

theASICguy — Thu, 14 Aug 2008 22:13:30 GMT

(Mike: Same comment posted on JL's blog). It seems to me that there are (at least) two areas that would need to be standardized to establish "compatibility" between the methodologies and the related VIP:

1) The simulation phases. AVM and eRM had different phases that ran the simulation (e.g. new, post_new, elaborate, pre_run, run, etc...). The OVM reconciles those differences by combining, borrowing, merging, etc. to create the new set of simulation phases. All OVM components support those phases, via methods, so that the verification components run in-sync. VMM has a similar (but slightly different) set of phases that would have to be reconciled. I supposed this could be done with wrapper methods, but it would be cumbersome and would need to be done for each component.

2) The class hierarchy. Again, AVM and eRM has different but similar classes that were merged as part of OVM. As I understand, even more of that will appear in OVM 2.0. For VMM, the lower level classes (e.g. monitors, drivers)could probably stay the same since those would be inside VIP, but the classes and methods used to communicate outside the VIP would need to be reconciled. VMM uses channels whereas OVM uses TLM FIFOs. VMM uses Callbacks. I think this will be hard to reconcile.

In short, although the VMM class library for Questa and IES is a necessary first step for running VMM legacy code, there is still a lot of work that needs to be done to make them actually play together in a simulation. Until someone figures out how that is done, any claims by either Mentor or Cadence that you can now run legacy VMM with OVM are marketing BS.

harry the ASIC guy

JL Gray — Thu, 14 Aug 2008 21:39:27 GMT

Welcome to the blogosphere, Mike ;-). Actually, the VMM does support layered stimulus generation in the form of VMM scenarios. Though few people seem to use them in the same way as OVM sequences and virtual sequences it is possible to create regular or multi-stream scenario generators in the VMM. Check out the "Multi-Steream Generation" alternate guideline 5-32 from the VMM book. I believe this is similar to push-mode sequences in the eRM (which are not supported in the current version of the OVM). JL