UVM-EA Release Now Available
DAC 2010: My Personal "Must See" List

UVM-EA Release Details

As I mentioned earlier in the week, the Universal Verification Methodology – Early Adopter release (UVM-EA) was announced on Monday and can be downloaded from the Accellera website. The process for putting together this release has been both exhilarating and frustrating, and it has highlighted (at least for me) the potentially transformative impact wide adoption of this library could have on the industry. Many users, from those with the most basic skills to those with the most advanced, have held off selecting a commercially available verification methodology for SystemVerilog. Initially, this may have been because they did not want to be locked in to a specific SystemVerilog simulator, though until recently (and, to be honest, still somewhat today), it was extremely difficult to write code that compiled on all three major simulators regardless of methodology. Some felt the VMM and OVM were too complex; others felt the libraries were ill-suited to their particular needs. 

Though I doubt anyone is going to stop what they’re doing and adopt the UVM mid-project, I believe engineers starting new verification efforts will take a serious look at the UVM.

So, what, exactly, is in the UVM-EA release? The release was based on, but is not completely backward-compatible with, the OVM 2.1.1. If you are not using callbacks or the objection mechanism in the OVM 2.1.1 you should not see any compatibility issues. For current OVM users, your first step to UVM adoption will be to run the OVM_UVM_Rename.pl script located in the bin directory of the UVM distribution.

## For e.g:
## % perl OVM_UVM_Rename.pl -top_dir /xyz/abc/src

The script will convert ovm’s to uvm’s, and rename “tlm_” to “uvm_tlm_”. Next, take some time to familiarize yourself with new and updated features such as:

  • Enhanced callback capabilities – not directly backward compatible with the OVM
  • Enhanced objection mechanism
  • Added a “report catcher” to allow users to catch and throw log messages

You’re probably wondering what is meant by a “report catcher”. The easiest way to explain what the report catcher does is by example. Here is an example taken from the UVM Reference Guide:

class my_error_demoter extends uvm_report_catcher;
  function new(string name="my_error_demoter");
    super.new(name);
  endfunction
  //This example demotes "MY_ID" errors to an info message
  function action_e catch();
    if(get_severity() == UVM_ERROR && get_id() == "MY_ID")
      set_severity(UVM_INFO);
    return THROW;
  endfunction
endclass

my_error_demoter demoter = new;
initial begin
// Catchers are callbacks on report objects (components are report
// objects, so catchers can be attached to components).

// To affect all reporters, use null for the object
uvm_report_cb::add(null, demoter);

// To affect some specific object use the specific reporter
uvm_report_cb::add(mytest.myenv.myagent.mydriver, demoter);

// To affect some set of components using the component name
uvm_report_cb::add_by_name("*.*driver", demoter);
end

There are good reasons for and against adopting the UVM. Here are a few things to consider:

  • Does the verification IP you use interoperate with the UVM?
  • How substantial is your current verification environment? If you are not already using the OVM the amount of work required could be substantial to fully adopt the UVM.
  • Are others who rely on your code willing and/or able to switch to the UVM?
  • For those not using the VMM or OVM, is your team skilled in object oriented programming techniques? If not, be prepared – advanced verification techniques require more than a basic understanding of good programming practices.
  • Do you like to be an early adopter, or do you prefer to wait until the dust settles?
  • Do you prefer to use the methodology library that comes prepackaged with your simulator, or are you ok with using the latest source version directly?
  • Does the version of your simulator support all of the SystemVerilog constructs used in the UVM?

Here are some equally bad reasons you should not use when making your decision:

  • There is no documentation or support for the UVM
    • Wrong – The UVM comes with an enhanced user guide and reference documentation. Most OVM documentation still applies to the UVM.
  • The UVM is not “production quality”
    • Wrong – My understanding is that at least one (if not both) authors of the OVM have run their production test suites on the UVM.
  • No one else is using the UVM
    • Well… True enough, but many people are using the OVM, upon which the UVM is based.
  • I am morally opposed to the letter ‘U’

One final note. The current release is marked “EA” for “Early Adopter”. The official 1.0 release of the UVM will may be sometime late summer and could contain any number of new features, depending on user feedback and the number of volunteers willing to contribute time to architecting, coding, and testing these features.

Comments