There were a lot of highlights from DVCon when it comes to SVUnit. In fact, it was the most successful three day stretch I’ve had in a very long time. From verification engineers in particular, it was the first time I had the feeling that SVUnit is gaining genuine acceptance. The stories and experience I’m finding in people are fantastic. Interest and usage is growing. Everything is awesome…
The wave of momentum within verification teams makes it apparent that SVUnit registers as a mere ripple for designers. Relatively speaking, I have very few conversations with designers about SVUnit. It’s become pretty obvious I’ve given them little to talk about and left them behind.
(Before I share how I think it happened, I feel like I need to apologize to designers – sorry! – and let you know I’m coming back for you.)
When we first released SVUnit as open-source, my strategy was to appeal to the front-end design and verification community at large by suggesting the quality of the code we were producing could be much better than it was. SVUnit is equally useful for design and verification so that felt like the right approach.
Time passed. I didn’t make much progress to start. I figured the all inclusive message was too general and that narrowing my focus would help me reach more people. Considering I’m a verification engineer and that my success had come in writing testbench code, focusing on verification made sense. Effectively, that meant cutting the potential user base in half. Further than that, though, I started to focus on how UVM was making our lives hell’ish with extra complexity and how we could use SVUnit to verify the complexity as individuals before it spilled over to the rest of our teams. Usage picked up considerably from there. Not surprisingly, unit testing of UVM testbench components has become the documented success to date.
Naively, I thought the growing user-base would become strong enough that its collective experience would naturally spill into design. With great results how could it not? Design and verification would reunite with common techniques for writing Verilog RTL and testbench code. Together we’d be back on track, working toward the original goal of improving code quality in front-end development.
Unfortunately, SVUnit hasn’t done much yet in terms of reuniting design and verification. The optimist in me suggests that we just need more time. The skeptic tells me the benefits of focusing on UVM has come at the cost of pushing designers away. The pessimist suggests that by continuing on the current course I’ll do more to exacerbate the rift between design and verification than bring them back together. SVUnit will become yet another tool for ignoring the needs of designers just as every other advanced verification technique has been used to ignore them.
Hence the apology… and a reset.
For design engineers, the intended and most important audience for SVUnit, this is what I can tell you…
- Forget about design, verification and all the tools, techniques and languages that divide us, SVUnit is for people that code Verilog. Simple as that. There’s no other requirement.
- SVUnit is a very lightweight framework with simple command-line scripting that can help you avoid much of the throw-away ad-hoc testbench development you do now. It’s perfect for smoke-testing. Even better if you want to go further than smoke testing.
- Unpackaging SVUnit – everything from download to running a test – takes about an hour. Ramp-up to the point where you’re productive is probably a couple weeks or less.
- You both instantiate your design module(s) and write tests in a testcase template (SVUnit comes with a script to generate those). The template is bare bones; there are placeholders for module instances and tests. It won’t quite fit on your monitor but it’s mostly comments anyway.
- You can put anything you want in a test case template. You can start from scratch and/or instantiate test utilities you’ve built previously and/or instantiate the universe. A testcase template is just a Verilog module; you can take it as far as you want.
- The testcase template is basically Verilog. There’s a bit of Systemverilog under the hood, but nothing that will get in your way.
- There is no required knowledge of the Systemverilog testbench constructs, OO programming, UVM or any of the other language nonsense we verification engineers have become preoccupied with over the last decade and a half.
- I see unit tests as very short directed tests; targeted and to the point. You can have randomization if you want but you don’t have to. In fact, I use very little randomization in unit tests and prefer none at all because I don’t like to guess at what I’m looking at.
- SVUnit has simple assertion and reporting facilities to mark passing and failing tests. I’ll admit the log file you get out of a sim is a bit wordy, but you get what you need.
- SVUnit is fast. If you write short tests, it’s reasonable to expect hundreds to run in less than a minute. You can also run tests against several modules in the same sim. SVUnit will run unit tests against each module sequentially, one module at a time.
This isn’t the end of it, but for most of the designers I’ve been ignoring I’m hoping it’s got you thinking in the right direction. There’s more information on the getting started page when you’re ready for the next step. There’s also a user guide with more detailed information. Finally, I’d encourage you to join the SVUnit User Group so you can post questions and take part in discussions with other users.
Lastly, over the next few months I’ll try and find the time to add more design relevant examples to the release package. That’s another area where verification engineers are better served but we can change that.
There it is. An all-in-one apology and re-introduction to SVUnit for the people I intended to help from the very beginning! Questions or concerns, you can get me by email at email@example.com. Better yet, you can praise, mock or shred SVUnit in the user group. All feedback welcome. Bonus points for recruiting opinions from other design engineers!