Back in February, 2012, Mentor started promoting a new method for building UVM testbenches. It was a 3 step method called UVM Express and it suggested a methodical way of adopting UVM by separately focusing on BFM development, coverage and stimulus. Mentor still has material on their website, but having heard very little of it since, I get the idea it fizzled out.

When it was first announced, I thought UVM Express was a great idea. Now I think it’s a shame that its disappeared. I know it’s almost 4 years later, but considering UVM seems here to stay for the foreseeable future, I’d like to see Mentor give UVM Express another shot. I’d like to see a UVM Express 2015. So much so that I’ve given Mentor a head start.

Introducing UVM Express 2015!

We’ll start by revising the marketing collateral and the first impression from the UVM Express methodology page on the Verification Academy.

What’s immediately evident on the methodology page is that Mentor chose to promote UVM Express very cautiously. Instead of risking confusion with their experienced UVM user base by coming strong with UVM Express, Mentor promoted it as a method for beginners and inexperienced teams. Assuming the massive investment already made in UVM, I suppose targeting the beginner audience is understandable. I think it’s also safe to assume this strategy played a big part in it fizzling out. From the methodology page…

If you’re like me, you’ll see the problem is in the table where they describe a verification team that doesn’t exist. Whether in name or in spirit, every team has a lead; it’s rare that SoC teams dare to mix design and verification; nor would any forward looking verification engineer pass up the opportunity to learn an HVL. Even if someone does admit to being in all three categories, “Think about using UVM Express” is hardly the way to capitalize. All together, I read this as something along the lines of UVM Express could maybe make you more productive, possibly… though unfortunately, we can’t really recommend it.

Not overly convincing.

For UVM Express 2015, I’d propose something like this…

 

Sure the exact wording may need a little work, but the message is bang on, no? UVM is complicated. In using UVM, teams have easily overrun schedules by months on their way to disproving the productivity benefits. And you can’t tell me designers like UVM; to them it’s a vortex of random stimulus and confusing language constructs that sucks in and obliterates rational decisions. So UVM Express 2015 is not a baby step toward ‘full uvm’ – whatever that means. UVM Express 2015 is a reset. It’s an incremental method for implementation that stresses early results and a usage model that is designer friendly. These characteristics are important to everyone, which is why I’d recommend UVM Express 2015 to anyone that’s using or planning on using UVM.

Step 1

I wouldn’t change step 1 from what was originally published. I think it’s good as is. I’ve used the guidance in step 1 to partition my BFM functionality between the UVM driver (the TLM connectivity) and a Systemverilog interface (all the pin wiggling) and it’s worked well. It’s a natural divide that provides the option of using just the interface in a more basic, yet practical, testbench arrangement. So if we’re looking back at the methodology page, UVM Express 2015 has no change for step 1.

Step 2

This is where things change for me. The methodology page describes step 2 as one that focuses on sequence generation:

This session describes how to add constrained-random stimulus generation to an existing BFM based testbench, in order to improve the productivity of the test writer, and to improve the quality of the coverage achieved.

I didn’t see the problem with step 2 until I tried it the first time. Bottom line, until the checking and functional coverage are added to a testbench, random stimulus is just throwing needles into your haystack. You don’t know what stimulus is being generated or if your DUT is responding appropriately.

A change for UVM Express 2015 is that step 2 focuses on the automated checking instead of stimulus because it gives you the option of writing directed tests using the interfaces you developed in step 1. You’re also prepping for future tests that use constrained random stimulus.

Step 3

Step 3 from the original UVM Express is dedicated to functional coverage:

This session describes how to add functional coverage to an existing BFM based testbench, in order to check how well the tests are supporting the desired coverage.

Random stimulus cannot exist without automated checking. That’s a problem we fix in UVM Express 2015 step 2. Random stimulus also cannot exist without functional coverage, which is what we fix in UVM Express 2015 step 3.

In UVM Express 2015 step 3, stimulus and functional coverage are added concurrently; add a sequence, implement the corresponding coverage, repeat until done. At step 3, a team is basically at ‘full UVM’ and well on their way to coverage closure. The difference is that the team got there in a very practical and productive way by incrementally focusing on important parts of the testbench that (a) are immediately productive; and (b) build toward the end goal capability of constrained random verification.

UVM Express 2015 Coming Soon?

I think Mentor almost had it right with UVM Express. The steps may have been a little off, but the idea of incremental adoption and implementation is a great one that I’d rather not see forgotten. I think a rejig to match the steps I have here and stronger marketing could position UVM Express 2015 as a very natural, productive and repeatable method for building some or all of a UVM testbench.

UVM isn’t going away anytime soon. Without knowing it, I think UVM Express 2015 is exactly what a lot of development teams are looking for. In fact, I honestly doubt teams can gain the advertised productivity benefits from UVM without it. So if you’ve got a favorite Mentor technologist, why don’t you suggest they get working on it!

-neil