Happy Birthday UVM! A Very Grown-Up 10-Year-Old

.The UVM standard was first released by Accellera 10 years ago this month and is now by far the leading methodology for functionally verifying logic designs, especially at the block level. As I write, DVCon fast approaches so I talked to Tom Fitzpatrick, Verification Technologist at Siemens EDA (Mentor Graphics) for a perspective. Tom has been intimately evolved in committee activity on defining UVM, representing at different times each of multiple EDA vendors, so he knows whereof he speaks. We talked about how the standard emerged, where it is today and a look into where the committee is planning further growth.

History

Successful standards most often build on successful proprietary/pseudo-open implementations. Back in 2004 Mentor had AVM and Cadence had eRM. They agreed in principle to partner on a common standard, OVM, which took a little while to get off the ground as some tools were still completing their SystemVerilog support. When both were ready, they locked themselves in a hotel room in the Bay Area for a week. Agreeing this had to be based on SystemVerilog, they pulled in concepts from AVM and eRM, kicked around and refined ideas, converged on an OVM definition and donated it to Accellera.

Synopsys were already doing very nicely with VMM, but acknowledged that momentum was building behind OVM. They decided to jump in also, participating in the definition and donating the register abstraction language from VMM. To satisfy honor all round, this evolved standard was renamed to UVM. And that’s how UVM 1.0 was born, in February of 2011.

I asked Tom if he could share a little behind the scenes insight, for those of us who wonder why such collaborations don’t seem to produce definitions everywhere grounded in pure reason. He chuckled and admitted that some choices are made for technical reasons and some for political reasons. Even SystemVerilog has features defined to carry across some contributor-preferred methodologies. The same applies with the UVM definition. In fairness to vendors, I’m sure each is looking ahead to how they’re going to migrate their customers from legacy investments. Some level of accommodation is going to be needed for that reason alone. Then again, sometimes I’m sure it’s simply partisan pride in their own inventions. That’s an unavoidable reality in collaboration. Wise standards leaders know how to progress while keeping all participants reasonably happy.

Adoption

Mentor does regular blind surveys on verification through the Wilson Group, so they can say with confidence that almost 80% of ASIC design projects are using UVM and 50% of FPGA projects. (FPGAs are now so complex that verification – as opposed to burn and churn – has become very important, for prototyping and coverage reasons.) Tom acknowledged that most users focus on block-level verification. That said, big design houses have already built extensive libraries on top of this stack. Which I take as a measure of a truly successful standard.

Of the 20% who aren’t using UVM, Tom felt that the majority who are still on legacy standards rely on cost-of-switching arguments – “what we have works and we don’t have time to change”. An argument we can all relate to, but then again… All IP vendors have switched to UVM because they have to service customers who demand UVM support. And a high percentage of job postings for verification engineers explicitly list UVM experience as a requirement. Momentum is heavily behind UVM. Being a holdout is only going to get lonelier.

Looking ahead

I’ve covered some of this recently in my update with Lu Dai of Accellera. A few points particularly struck me the current discussion with Tom. First, as a UVM guy through and through, he acknowledged that UVM doesn’t do a good job in running software. You can create UVM sequences and virtual sequences that mimic software, but when it comes to replacing the UVM agent with an actual processor model, you have to rewrite the sequence as software. That’s where PSS can take over. UVM still reigns supreme at the block level, but not for modeling software at the system level. PSS tasks still connect to UVM underneath and a continuing focus is on connections between PSS and UVM.

Another fascinating direction is on Python implementations of UVM. Tom told me that he and Ray Salemi talked about how many new college hires know nothing about Verilog or VHDL. But they they all know Python. Ray (who at Siemens supports mil-aero FPGA users) also mentioned that class of users have a natural resistance to using a standard based on SystemVerilog. Switch them to perceived neutral territory in Python and the resistance evaporates. I imagine the same may be true for FPGA applications in datacenters (reconfigurable networking for example). Python could lower the barrier to adoption for CS grads hired to deal with these strange FPGA beasts.

Tom is an entertaining guy to talk to. He tells me they are going to be pretty busy at (virtual) DVCon this year,. Sounds like they already have planned tutorials and updates on UVM. I haven’t seen the agenda yet but I’m sure we will soon. Meantime you can learn about Siemens EDA views on and support for UVM HERE.

Also Read:

The Five Pillars for Profitable Next Generation Electronic Systems

Probing UPF Dynamic Objects

Calibre DFM Adds Bidirectional DEF Integration