The UVM : Is it Safe?
Is It Safe?
It depends. What is the context? Economy? Geo-political situation? Teenage drivers? UVM?
I don’t know.
Do you feel safe when you cross the street?
Do you feel safe at Starbucks? In your own house?
Each person has a different comfort level.
That’s all fine. Real world stuff. But what about how you pays the bills? What about bringing home the bacon with the UVM? Is the UVM safe?
I don’t even know what that really means.
Safety In The UVM?
The UVM has been around for years, and has multiple versions with various features and bugs. Who knows if it is safe? I guess if you use it for awhile and it keeps chugging along, it is safe. But what happens with a new version? Should you upgrade? Is it safe?
What about the new bugs that come with any code base? 1-5 bugs per 100 lines of code. Or something like that. Each UVM release has lots of new lines of code, and with it, lots of new bugs. But maybe those bugs are harmless or in code I won’t use. What should I do?
What about some bugs that haven’t been fixed in any UVM from the planet Earth.
Random Stability
The UVM is *still* randomly unstable. There is an “unprotected new()” in set_severity_id_action().
Oops. There’s a new() there! Grabbing a random number off the list… Changing the future…
Here’s one that got fixed in uvm-1.2 – in one of my most hated functions: lookup_name()! in the uvm_resource stuff:
So, the “way to fix” random instability caused by new() is to use “process::self()”. There are 33 such occurrences in uvm-1.2. Did they get them all? (Hint: the one above got missed). Is It Safe? Note: there are 37 such occurrences in uvm-ieee. That’s 4 that got missed when uvm-1.2 came out. Fixed in uvm-ieee. Is It Safe?
Upgrade Now?
Go ahead and upgrade. A side-effect of upgrading from uvm-1.1d to uvm-1.2, might be to exercise one of these changes to random number ordering which in turn might cause simulation results to no longer match. Is It Safe?
I don’t know. Generally we recommend that users stick with whatever UVM version they are using. That’s it. Stick with your UVM because it really doesn’t matter what version you are using. You should be using the UVM. We should ALL be using the UVM. It is an easy way to improve verification productivity. But, like most things, you should pay attention to what you are doing. Then just maybe, you’ll be safe.
Want to hear more? I have lots more to say on this and I love to talk about the UVM, so…
Come to DVClub
Come visit DVClub in San Jose next week – Free Lunch on Friday, November 8 at Dave And Buster’s in Milpitas from 11:30 to 2:00.
I’ll be romping through the fun and history and horrors of the UVM.
And James and Glenn from Ericsson will be there talking about 5G. I’ve seen their 5G talk. It is really interesting.
Sign up today – it’s free – DVClub just needs to know who is coming to have enough food and chairs. But sign up now, the last one filled up fast. See you Friday, November 8 at Dave and Buster’s for free food and some UVM fun. Register here now.
Comments
Leave a Reply
You must be logged in to post a comment.
I suspect what most people mean by “Can it be trusted?” is really “Is it predictable, and is it robust?”
some examples:
1) Will it generate identical results on simulators from different vendors
2) will it generate identical results on the same simulator with varying compile options
3) will it generate identical results on different versions of the simulator from a single vendor
4) Will it detect and report invalid data (vs. just having internal data corruption that is either unreported or results in CTD).
Tool changes are important to keep in tune with the changing dynamics. A well integrated tool can bring in a whole different perspective and can eke out those nasty yet difficult to find scenarios.
The main factor that should be your clinching factor would be to adequately assess the changes that comes along with it, look for the most opportune moment and seize the benefit of the vast community that will go about a similar upgradation.
Ingrain into the system that such upgrades do come in with a cost. Appropriate mitigation strategies mainly the pro-active ones can significantly reduce the penalty you end up paying. An elaborate snippet suite to adequately validate all possible usage scenarios (ever-growing and not a stagnant one) is the best answer to this often-repetitive requirement.
The Verissimo linter runs continuously every 6 hours on the UVM library master branch and all open pull request branches. Speaking of random stability, there are 194 random unstable functions, look for SVTB.15.7.1.rootCause on the master branch here: https://dvteclipse.com/uvm-verissimo/main/index.html.
Unfortunately there are a lot of users out there, but only a bunch of contributors. I would be nice to get more contributors involved, this will definitely improve safety. Sticking with a specific version doesn’t really sound like safety improvement…
UVM is not safe. UVM packer case: https://forums.accellera.org/topic/6572-annoying-and-useless-packer-implementation-in-the-uvm-2017-v10-library-code-release/
– no thread-safe due singleton instances with shared states
– unexpected side effects thanks to singletons in coreservice instance like packer, comparer, copier, …
– unitialized states like in the UVM packer class
UVM should be contributed in GitLab by open source community and more expierenced and skilled programmers. Current UVM implementation is more problematic than become a real solver.