Let me take you back a few years to my first job as an ASIC verification engineer. It was 2000 and things were a lot different. The notion of “architecting a testbench” didn’t really exist the way it does today. Design was cool and verification was where junior engineers started. Constrained random verification hadn’t hit the mainstream. There wasn’t much functional coverage to speak of. I think Specman and Vera were around but the user-base was relatively small. There was no Systemverilog and there was no UVM. Basically, we were back in the stone age of directed testing. Any knucklehead could do it. Thankfully, I was perfectly qualified. Continue reading
DVCon call for papers hit my inbox last week. This time around, to possibly save myself the effort, I figured it might be more productive to let other people decide whether or not mine is a topic they’d like to see at DVCon. I’ve got a draft title and abstract so far…
How UVM-1.1d Makes the Case For Unit Testing
In six weeks, two verification engineers discovered 10 defects in the UVM-1.1d release. The defects were not lurking in the shadows of complex corner scenarios; it didn’t take hours of constrained-random stimulus to discover them; nor was there any need for functional coverage with intelligent feedback. These were simple, obvious defects discovered with an equally simple and obvious technique. It’s called unit testing and it comes from software development where the value placed on code quality and maintainability is higher than what we aspire to in hardware.
UVM-UTest is an open-source project with the goal of demonstrating how unit testing can be used to bring software level quality and maintainability to design and testbench code. This paper documents the development of UVM-UTest, how it was conceived, statistics and style for unit tests written, its success in terms of defects found in UVM-1.1d, the lessons learned and recommendations for applying unit testing beyond the UVM. The paper concludes by introducing a new UVM component, the uvm_boat_anchor, that further demonstrates the perils of continuing to ignore the value of this basic yet entirely necessary technique.
I’ve submitted proposals twice in the last few years. Neither was accepted. Agile development and test-driven development – the topics I’ve submitted – aren’t your average mainstream, audience grabbing topics so that wasn’t overly surprising. Maybe this proposal is different. Or maybe it’s not. Either way, I’m leaving it for you to decide.Sorry, there are no polls available at the moment.
If there’s enough interest, I’ll submit it and see what happens. If you really like the abstract, share it with your colleagues so they can vote, too. Or if you hate it, may as well share it, anyway. I don’t mind people seeing my incredibly terrible ideas. I’ll just entertain myself with it.
Proposals are due Aug 27th so share the link and get your votes in asap!
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.
The point of the open-source UVM-UTest project we’ve been working on is to demonstrate how unit tests can be used to lock down the functionality of legacy code. Being able to run the unit tests means that when you’re changing code you can verify existing features won’t break during maintenance. We think that’s valuable. A nice side benefit of the project is that we can also show unit testing as being effective for increasing the quality of code hardware engineers write. How can we say that? Because over a 5 week period we found 10 defects in the UVM 1.1d release. Continue reading
Verifying error conditions and UVM testbench checkers just got easier! The SVUnit UVM report mock lets you automate testing of UVM errors and fatals to increase confidence that the checkers in your testbench are defect free. The SVUnit UVM report mock is a scoreboard style checker where actual and expected errors are logged and compared to trigger a PASS/FAIL result.
Here’s how it works… Continue reading
I’ve had a lot of reading and commenting on my last post Time to Blow Up UVM. Now I’m looking for an anonymous show of hands to see if I’m on the mark or completely out to lunch regarding UVM.Sorry, there are no polls available at the moment.
Just as it seems the verification community has converged on a methodology – a universal methodology as it were – that finally meets the needs of EDA vendors, IP providers and users, along comes somebody to suggest we should blow things up entirely and start again.
‘Somebody’ is me.
Here goes. Continue reading
I think it’s been about 9 months since Mentor Graphics announced UVM Express. While I hope people are seeing value in the idea of UVM Express, I haven’t heard much about it since it was announced which makes me wonder if it’s hit it’s mark. Continue reading
I can honestly say that as of a couple weeks ago, I’ve gone further with SVUnit than I thought was realistic when I first starting looking at it. Having done more TDD, written more tests and recently finished step 2 of my UVM Express example, I’ve come to the conclusion there’s value in unit testing anything! That includes coverage groups and UVM agents… which I talk about here.