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.
[poll id=”4″]
-neil
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.
[poll id=”4″]
-neil
Hi Neil. While I’m sympathetic to your position, it’s important to keep all this in perspective. It’s doesn’t matter if its eRM, RVM, AVM, OVM, VMM or UVM, the cost/benefit of using one of these methodologies is always going to tilt in favour of using a formal methodology. It’s true that there is a significant cost/effort barrier to overcome if your team is going to realize any benefits from a methodology. In my experience, this cost is always less than the benefits. Spend time with it, learn to make it work for you. All of these methodologies are incredibly flexible, so your team can cherry pick the features that meet their needs.
Lets not go throwing the baby out with the bath water. 🙂
Cheers,
—mike
hey Mike,
You’re certainly not going to sympathize with my position, then – what I wouldn’t do to get rid of SystemVerilog, too.
Baby? Bath water? I don’t even want the damned tub! 🙂
The UVM has a nice approach to register models by its register model (once you learn how to use it). This can significantly make the work easier during the time when the implementation of both the design and verification is running and the registers are often changing. I know this could also be done in a non-UVM enviroment by using structures and implementing your own accesss functions, but I think the UVM reg model approach is pretty good.
On the other hand, since UVM has soo many classes and objects etc., it takes much longer to compile testcases and this just slows down your work if you are developing testcases.
UVM is also very complex and without learning quite a lot first, it can be hard to use.