UVM Polymorphism is Your Friend

Rich Edelman of Siemens EDA recently released a paper on this topic. I’ve known Rich since our days together back in National Semi. And I’ve always been impressed by his ability to make a complex topic more understandable to us lesser mortals. He tackles a tough one in this paper – a complex concept (polymorphism) in a complex domain (UVM). As best I can tell, he pulls the trick off again, though this is a view from someone who is already wading out of his depth in UVM. Which got me thinking about a talk by Avidan Efody that I blogged on recently, “Why designers hate us.”

More capable technology, smaller audience

Avidan, a verification guy at Apple, is probably as expert as they come in UVM and all its capabilities. But he also can see some of the downsides of the standard, especially in narrowing the audience, limited value in what he calls “stupid checks” and some other areas. See HERE for more on his talk. His point being that as UVM has become more and more capable to meet the needs of its core audience (professional hardware verifiers), it has become less and less accessible to everyone else. RTL designers must either wait on testbenches for debug (weeks to months, not exactly shift left) or cook their own tests in SystemVerilog. They still need automation, so they start hooking Python to their SV, or better yet cocotb. Then they can do their unit level testing without any need for the verification team or UVM.

Maybe this divergence between designer testing and mainstream verification is just the way it has to be. I don’t see a convergence being possible unless UVM crafts a simpler entry point for designers, or some cocotb look-alike or link to cocotb. Without all the classes and factories and other complications.

But I digress.

Classes and Polymorphism

The production verification world needs and welcomes UVM with all its capabilities. This is Rich’s audience and here he wants to help those not already at an expert level to uplevel. Even for these relative experts, UVM is still a complex world, full of strange magic. Some of that magic is in reusability of an unfamiliar type, through polymorphism.

A significant aspect of the UVM is its class-based structure. Classes allow you to define object types which not only encapsulate the parameters of the object (e.g., center, width, length for a geometric object) but also the method that can operate on those objects. Which for a user of the object abstracts away all that internal complexity. They just need methods to draw, print, move, etc. the object.

Reuse enters through allowing a class to be defined as extension to an existing class. All the same parameters and methods, with a few new ones added. And/or maybe a few of the existing parameters/methods overridden. And you can extend extended classes and so on. This is polymorphism – variants on a common core. So far, so obvious. The standard examples, like the graphic in this article don’t look very compelling.

Rich however uses polymorphism judiciously (his word) and selectively to define a few key capabilities, such as an interrupt sequence class. Reusing what is already defined in UVM to better meet a specific objective.

As I said, I’m way out of my depth on this stuff, but I do trust that Rich knows what he is talking about. You can read the white paper HERE.