UVM World site now open

UVM
1

Since many OVM users are asking about the status of Accellera’s Universal Verification Methodology (UVM) standard, this is to let you know that Cadence has established the UVM World site. This site provides information on the UVM and its close relationship with the OVM, as well as links to the official Accellera UVM download page. Please check it out at www.uvmworld.org!

2

Does UVM mean that OVM/VMM will die eventually ? If we have a standard methodology like UVM people will certainly prefer it over OVM/VMM.

3

Actually UVM is based on OVM 2.1.1 so it is very simple to migrate your OVM code to UVM with a small sed script included in the UVM tarball which effectively converts ovm_* to uvm_*.

Here is a cut & paste from the release notes:

The UVM is built on the same code base as OVM-2.1.1, with the following
new feature enhancements which are described in greater detail in the
“New Features” section below and any API changes described in the
“API Changes” section.
- All ovm_* symbols converted to uvm_*.
- Enhancements to the OVM callback facility, including a new message
catching facility. These enhancements introduce some minor backward
incompatibilities to the OVM callback facility.
- Enhancements to the OVM objection mechanism. These enhancements
introduce some minor backward incompatibilities to the OVM objection
mechanism.

4

All deprecated features of OVM has been removed in UVM (code removed), so if you are using any deprecated code in OVM, then that needs to be removed and use the alternative method suggested in OVM.

5

Is UVM available now for the Verification engineers.

Thanks in Advance.
Maverick

6

See http://blogs.mentor.com/verificationhorizons/blog/2010/06/28/the-reports-of-ovm%E2%80%99s-death-are-greatly-exaggerated-with-apologies-to-mark-twain/

7

UVM is ready for verification engineers to use immediately. You can get some more information from here: http://www.cadence.com/Community/blogs/fv/archive/2010/07/07/why-the-uvm-is-ready-for-production-use-today-part-3.aspx?postID=202881

but the most important point is backward compatibility. A statement from the chair of the Accellera committee is posted here on UVMWorld: http://www.uvmworld.org/forums/showthread.php?69-Backward-Compatibility-of-UVM-1.0-from-UVM-1.0EA

8

In my opinion, production worthiness has nothing to do with backward compatibility; backward incompatibilities are present in production software all the time. We can only hope the Accellera committee sets a high bar on backward compatibility and only changes something when the existing functionality is proven to be unworkable.

Ideally like everyone else, I want only one methodology to deal with, but practically, what people look for is stability and long term commitment to support. They want to know that if they start today using a base class library, it will be supported for the life of their project. That means if they find a critical bug in that library, they either need patch releases in a timely manner, or have the capability to patch the code on their own. Other than setting up a bug tracking system, I have not seen how Accellera will deliver bug-fix only patch releases for the UVM.

So the question of using the UVM today is strickly a risk management issue. How close will Accellera stick to their plan of not introducing backward incompatibilities, and if they do make changes, how willing am I to make the necessary changes to my code? And if I find a critical bug in the UVM, how willing am I to patch the library myself? For Early Adopters, the answer is usually yes, they are willing.

Dave Rich

9

Dave,

This is an interesting history lesson because it mimics the early days of OVM, but there are some marked differences:

  • UVM has a bug tracking mantis, OVM did not. This was one of JL Gray’s OVM complaints and remains true today
  • UVM has complete industry support. This is the fastest path to the most resilient library and methodology
  • OVM posted about 3 bug-fix updates per year. That’s a reasonable expectation for UVM
  • Both Cadence and Mentor have said there will be no new OVM features. The future is UVM and its there for us to access today.

There is no doubt that any group choosing a methodology has to assess risk. Given that UVM is a scripted change from OVM, the risk factor for UVM starts as low as OVM. With your point about how UVM is maintaining backward compatibility and the points I’ve added here about more bug tracking transparency, the risk in choosing UVM is actually lower than OVM.

Cadence customers have made this logical assessment already and are starting their migrations.

=Adam Sherilog

10

Adam,

I agree with most of what you say - the future is UVM. But the purpose of my rant is not for argument’s sake, it is to motivate the committee to focus on stability. As much as users want unification of methodology, they don’t want change in methodology. These two desires can be in conflict, but the UVM has taken care of unification part by seeding the code with OVM 2.1.1. Now comes the hard part.

It’s true OVM didn’t have a public bug tracking system, but we had a place in this forum to report bugs. Getting the Mantis system up for entering bugs is great, but somebody still has to go through the process of assigning and addressing those bugs. This is hard enough with just two entities, now we have a whole committee of entities. That’s where I see the greatest risk. Can the committee get out of the mode of adding new features and focus on addressing stability? They have the same problem in the IEEE SystemVerilog committee, there’s nothing new here except they have an 8-year head start.

I do think selection of a register package is a critical new feature and its completion may be the tipping point people need to begin migration from the OVM to UVM.

Any comments from users?

Dave

Dave Rich