I recently came across the following comment on verificationguild.com in response to my posting of a link to the first publicly available, v0.1 version of SVUnit…

I have attempted to read each of the blog posts about svunit, but they are mostly a bunch of arguments about why I should use it and how great testing is. Are there any code examples I could look at? I’m still not totally clear on what I should use svunit for. Is it for testing RTL design code? You mention being able to test UVM classes. Is it for testing my testbench code (which is so meta)? My team has talked about “micro testbenches” that designers could quickly write while developing, since UVM testbenches are beyond the scope of their need. Could svunit fill that need?

It’s pretty easy to spot the frustration in the first sentence. When someone talks about “attempting to read” something, it probably means they tried as hard as they could to get through it, hoping to eventually find what they were looking for and in the end they’ve come up short… which means I’ve come up short.

Looks like the message I’m sending is getting a bit foggy so let’s rewind way back to the beginning and answer the simple question: what do I do with SVUnit? I’ll try and break this down as best I can.

All Hardware Developers

First off, only the most exceptional of the absolutely exceptional are able to write bug free code. The rest of us make mistakes and a lot of them. If you’re a person that wants the code you’re writing to actually work, you’re going to need to test it. Unit testing or TDD with SVUnit helps you test your code before you use it. Think of it like a simple, miniature, automated test framework for every line of Systemverilog code you write.

Hardware developers can use SVUnit to test any Systemverilog module, interface or class. All of those are units, so when I talk about unit testing I’m talking about verifying a module, interface or class on it’s own. In my mind, it’s the smaller pieces where unit testing applies as opposed to the sub-system and chip level testing most of us are used to. SVUnit is not for sub-system or chip level testing. It’s for writing simple yet thorough directed tests against the lower level units within sub-systems.

Verification Engineers

Verification engineers can use SVUnit to verify testbench components before they’re used to test some design. I used to think that wasn’t necessary, until it finally clicked in that the testbench is supposed to be the standard by which a design is measured. If you tend to find a lot of bugs in your testbench, your testbench code is poor quality which means the standard you’re holding your design is unacceptable.

Another way to look at it… if you’re a verification engineer that relies on a design to debug your testbench – a practice that is less than ideal to say the least, also one that I’d bet 99% of verification engineers have used – you need better code. You can use SVUnit to write better code. It’ll work for normal Systemverilog. It’ll also work if you use UVM.

Design Engineers

From what I’ve seen, designers have a habit of smoke testing their code and that’s about it. If their code passes a smoke test, it goes to the verification team to verify. That’s deferring responsibility for quality and making bugs somebody else’s problem. I’ll never suggest we don’t need separate teams for design and verification to avoid one person having sole responsibility for writing and testing code. But that doesn’t mean a designer can’t share responsibility for quality by unit testing their code before they dump it on a verification team.

Designers can use SVUnit to test internal design modules as they write them. You don’t need to be a UVM expert or anything like that to understand it. There’s no weeks long ramp up to figure out how to write test benches. It’s a simple jump start that can make unit level testing productive. A good way to start might be to write your smoke tests in SVUnit to get familiar with it, then see how far you can take it.

The Counter Argument…

“But it’s going to take a long time and I don’t think it’s productive to have designers do the same thing that the verification engineers are going to end up doing anyway! Verifiers verify. I don’t want designers to be burdened with testing, too! And if we test the testbench, then we also need to test the testbench tests, and then test the tests for the tests for the tests… blah, blah, blah.”

People still try and make those points but day-by-day I think they get sillier and sillier. If you’ve seen the results from this survey done for Mentor Graphics in 2010, you’ll have seen that verification engineers spend 32% of their time debugging code. If you’re spending a 3rd of your day debugging code, your code is… well… pretty bad. If you think it’s acceptable to spend that much time debugging code, don’t change what you’re doing and keep writing bad code. If it’s not acceptable, it’s time to drop these silly efficiency arguments and get on with writing better code.

Any Better?

Hopefully that doesn’t just muddle things up and actually makes things a little more clear. Unit testing or TDD with SVUnit is a way to write better code. It’s basic, it’s low risk, barrier to entry is low and portability is high. If you want to see SVUnit in action, it’s best to watch this video that explains how to get started.

In the end, I appreciate the feedback I get from places like verificationguild.com, Linkedin and everywhere else people comment. Being challenged is a great way for me to improve and help explain things the way SVUnit needs to be explained. If you find yourself sitting in an SVUnit blog fog not knowing where to start, I hope you feel like I’m listening and slowly zeroing in on a framework and an idea that helps you out!

-neil