If you saw the UVM boat anchor announcement last week you may have thought a 34 second ascii animation of a sailboat getting caught in the rain is a few hours of my time flushed down the drain and lost forever. Not true. Here’s why…

[youtube_sc url=WqWjWQu64MI width=640 height=480]

Watching the animation, in the top window you’ll see what looks like simulation log messages floating by. They look like log messages because they are log messages from a real sim running in the background. The ‘$cmd>’ messages are also real in that they’re piped to and drive the animation. Whether or not our friend on the sailboat  floats away into the sunshine or gets pounded by rain depends on the output of the uvm_boat_anchor.

This is what that code looks like. It’s pretty simple.

What I don’t show you is what’s happening inside the ba.weigh_anchor() routine (though I did hint at it earlier this week). The weigh_anchor() routine depends on properly functioning defects in the UVM that we found in UVM-UTest; properly functioning in that the code we verified as being wrong produces precisely the wrong result we expect. As long as nine out of the ten issues we filed remain open (the 10th isn’t really a functional issue), the weigh_anchor() routine returns true, the uvm_boat_anchor flips back into the boat and it sails away. If any of those defects are fixed… say in a uvm-1.1e release… the boat anchor breaks and the poor sailboat is caught in the rainstorm.

“That’s pretty stupid. Why would you write code that depends on a bunch of known defects?”

Think about it. We all write and rely on buggy code. Don’t kid yourself, it’s true. In fact, some people reading this may be relying on the same defects that the uvm_boat_anchor relies on to function properly (i.e. it may start raining on you when you get to uvm-1.1e). Inadvertently relying on buggy code is no good, obviously, because when that buggy code is fixed your code breaks. Think tool or IP upgrades that break the sims you’ve been running for months without issue. Two wrongs quietly making a right… all that time… until you upgrade and everything goes kaput. Then, you end up spending hours recovering…

…unless, that is, you’ve protected yourself from unforeseen changes the way we’re doing with UVM-UTest. We’ve started locking down functionality of the library with unit tests so if anything breaks, we know immediately. No coincidence, I built the same kind of protection into the uvm_boat_anchor (using TDD). If any of the nine UVM defects I rely on are fixed in a 1.1e release, the corresponding unit test will break thereby telling me exactly what’s happened. From there it’s a quick fix.

That’s the value of unit tests and the suggested value of our DVCon proposal. Without unit tests, if your code changes in ways you don’t expect at times you’re not expecting, whether it’s RTL, testbench IP, the UVM or a silly uvm_boat_anchor, you’re going to end up stuck.

How long you’re stuck for depends on the weight of the anchor and the depth of the water, neither of which you’ll have much control over ;).

-neil