UVM Is Not A Methodology (The TDD Remix)

Forgot about this in last week’s post! Another interesting question from the functional verification seminar I delivered in Mountain View a few weeks ago was: if you could only pick one or the other, would you rather use UVM or test-driven development? Of all the great questions that came up, that was by far the easiest to answer. My response…

I’d take TDD over UVM any day. No contest.

Now before we go too far here, I want to be clear that choosing between the two is a pure hypothetical. UVM or TDD is not an either/or choice. In fact, the first time I used TDD was on a project where I was also using UVM. There is no reason to choose one over the other. You can use both. In fact, if you’re using UVM you should use both… which takes me to the topic of the day.

Challenging the idea of UVM being a proper methodology is something I started in the spring of 2011 with an article called UVM Is Not A Methodology. Even though it’s been a couple years since I posted that article, I really don’t think I’d change anything with it today. I didn’t think UVM was a methodology at the time and nothing has happened since that has me thinking any differently. I would, however, like to offer an update to the People Centric Universal Verification Methodology I outline in UVM Is Not A Methodology. I forgot about TDD, which, after having used it, becomes an important practice for successfully building a UVM testbench.

I should have included TDD in UVM Is Not A Methodology. Had I done so, it would have looked a little like this…

Test-driven Development

I’ve heard UVM described as a go-fast-to-go-slow methodology. I like that description because I’ve seen UVM encourage rapid deployment of technology that ultimately slows teams down. One reason teams get bogged down is complexity, which is inherent to UVM. Another is high defect rates, a characteristic of the open-loop coding style used by most verification engineers. Combining the complexity of UVM with high defect rates results in nightmarish debug scenarios that eat schedule and demoralize teams. Relentlessly.

While we users can’t do much to address the complexity of UVM, we can address unacceptable defect rates. TDD is a very productive way of doing so. Teams can verify the functionality of agents, components and transactions before they’re used to ensure a high quality, highly functional UVM testbench.

So along with the practices I originally suggest in UVM Is Not A Methodology – a sustained training strategy, mentoring of new teammates, regular review cycles, early design integration, early model integration, incremental development/testing/coverage collection and organization specific refinement, I’d also propose TDD an an important part of turning UVM the framework into UVM the methodology.

…but all that said, if by some strange series of events it does ever come down to a decision between UVM and TDD, I’d take TDD any day. No contest.


Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.