The Most Descriptive UVM Tests Ever Written

If you want to know how the uvm_printer works, in detail, I don’t think you’ll find a better explanation anywhere than my unit tests. This comes after I went through a refactoring exercise in our open-source UVM-UTest project – that’s where we’re unit testing the code in the UVM framework – specifically for the purposes of making my code more readable.

Here’s one of the tests I’ve written to get the idea of where I’m going:

Screen Shot 2013-05-28 at 4.02.11 PM

The reason I’m happy with this is that as you can see in that snapshot, I think I’ve made my code human-friendly. When we got started with the UVM unit testing, I thought a descriptive test name would suffice. But after finding myself getting a little lazy, I accidentally took “descriptive” to the next level and ended up with the approach I’m showing here. In a nutshell, I have tests that:

  • focus on what is relevant;
  • exclude what is not relevant; and
  • are very english’y.

For those reasons, I think I’ve given people a chance at understanding what’s supposed to be happening.

Here’s a few more examples from that same file, all of which focus on the behaviour of the ‘print_int’ method:

Screen Shot 2013-05-28 at 4.02.42 PM

In case it’s not obvious, I’ll point out that I’m using a pattern of Given-When-Then to differentiate between setting up the UUT (Given), exercising it (When) and then confirming the result (Then). That pattern is something I’ve borrowed from a technique called behaviour-driven development (BDD) which I’ve written about before on BDD is an agile technique where a product is described as a list of behaviours. This as opposed to a bullet list of features or suite of acceptance tests, both of which hardware developers would be more familiar with. I find the Given-When-Then structure does improve the readability significantly so it’s something I’m going to continue experimenting with. With proper tooling, behaviours become an executable specification (see Cucumber for more on that). For this project, let’s consider what we have a poor man’s executable spec!

By the time we’re done with our UVM unit testing experiment, we should have several examples of how we’ve followed this approach; in the uvm_printer and elsewhere in the library.

Now… are these the most descriptive UVM tests ever written (like I suggest in the title)? I guess I don’t really know… but they’re certainly the most descriptive tests I’ve ever written which is why I figured them worth talking about here :).


PS: if you want to know more about UVM-UTest, you can take a look at my last post: We’re Unit Testing UVM

PPS: Pretty much everything I know about BDD came from a talk be Liz Keogh at Agile2012 in Dallas. Her talk called BDD: Look, no frameworks was quite good. Hopefully I haven’t mangled the message to badly!


About nosnhojn

I have been working in ASIC and FPGA development for more than 12 years at various IP and product development companies and now as a consultant with XtremeEDA Corp. My specialty for most of that time has been RTL functional verification where I have had a chance to work with some very experienced people and learn state of the art techniques. I really enjoy the challenges of being a verification engineer but as of late have come to wonder what lies beyond my verification bubble. That's lead me to agile software development and project management. There is a massive amount of material out there related to agile development. All of it is interesting and most of it should be applicable to hardware development in one form or another. So I'm here to find what agile concepts will work for hardware development and to help other developers use them successfully! You can find me at
This entry was posted in Functional Verification and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>