What’s New with UVM and UVM Checking?

About once a quarter, I touch base with Cristian Amitroaie, CEO and co-founder of AMIQ EDA, to see what’s new with the company, products, and users. Sometimes he surprises me, as he did earlier this year when he mentioned that their tools check about 150 rules for non-standard constructs in SystemVerilog and VHDL. When we talked last week, he surprised me again when he said they have announced a bunch of new rule checks for compliance to the Universal Verification Methodology (UVM). My response was that UVM has been around for years, and I know that AMIQ EDA has offered rule checks for it, so what could possibly be new? Cristian’s answers were quite interesting.

For a start, he reminded me that an updated version of the UVM standard, IEEE 1800.2-2020, was released last September. As with any new version of any standard, there are new features and new functionality included. The UVM standard documents an application programming interface (API) used by chip verification teams to write simulation models, testbenches, and tests. Thus, the new features are enabled by additional API functionality in the UVM standard. EDA vendors have been adding support for it, and users have started using it, so there are additional API rules checked in the AMIQ EDA Verissimo SystemVerilog Testbench Linter.

But the story is more complicated and intriguing than that. The new UVM release has also removed some outdated parts of the API, while marking others as “deprecated” and slated for removal in the future. This is common practice with updates to language and library standards, but it makes keeping up to date more challenging. Verissimo alerts verification engineers when they use deleted or deprecated functionality so that they can update their code before simulation tools drop support. Other API changes are more subtle in the 2020 standard, such as altered arguments or classes turned abstract that can no longer be instantiated. Verissimo has also added rule checks for compliance with these changes.

One usual aspect of UVM is that IEEE provides both the standard document and a “reference implementation” of the API library written in SystemVerilog. Cristian said that they developed their new checks based on the standard, and when they checked the reference implementation they found “a few methods, classes, macros, etc.” that were not annotated consistently with the latest version of the standard. He summarized the scope of “problematic” UVM API usage that they detect:

• Removed API = API definition that no longer exists in the IEEE library
• Deprecated API = API definition that will be removed from the IEEE library in the future
• Non-standard API = API definition that exists in the IEEE library, but is not documented in the standard
• Deviation API = API definition that exists in the IEEE library but whose implementation is not consistent with the standard and should be fixed (which may lead to backward compatibility issues)
• Contribution API = API definition that exists in the IEEE library, but is not part of the standard, that may be considered for future standardization
• Implementation API = API definition that exists in the IEEE library, but is neither part of the standard nor considered for future standardization

So, it seems to me that the level of checking that Verissimo provides helps IEEE create a better reference implementation library and helps users switching versions. Verification engineers clearly see the value in being able to check whether existing testbenches will work with the latest revision to the standard. UVM has a long history by now, with multiple versions released first by the Accellera EDA standards organization and later by the IEEE. There have been many API changes along the way, but there is doubtless a lot of old UVM code out there that is no longer compliant with the standard.

Cristian pointed out that the AMIQ EDA approach is not just to report rule violations, but also to propose possible fixes. For example, if Verissimo sees an API call to the deprecated “uvm_default_printer” it will recommend using “uvm_printer::get_default()” instead. Proactive suggestions are valuable when checking old code, and they also provide guidance when updating code or writing fresh code that uses the new API functionality available in IEEE 1800.2-2020. Finally, he noted that all testbench rule checks, including those for UVM, can be run in batch mode with Verissimo or interactively within the AMIQ EDA Design and Verification Tools (DVT) Eclipse Integrated Development Environment (IDE).

I found this whole conversation enlightening. Standards often evolve in ways that are neither monotonic nor simple, and UVM is no exception. It’s great that users have automated assistance when migrating to the latest version. I’d like to thank Cristian for his time and helpful information. You can keep an eye on https://dvteclipse.com/uvm-ieee-compliance, which AMIQ EDA updates as they add new rules to be checked. I wish you all the best as you harness the power of UVM to verify ever larger and even more complex chips.

Also Read

Why Would Anyone Perform Non-Standard Language Checks?

Does IDE Stand for Integrated Design Environment?

Don’t You Forget About “e”