DVCon: UVM Birds of a Feather
At the recent DVCon 2022, there was a?UVM Birds of a Feather?meeting. UVM stands for the Universal Verification Methodology. The meeting was free to anyone at DVCon, even with just an exhibit pass.?It?was led by Mark Strickland who is chair of the Accelera UVM Working Group. This group developed UVM and the most recent version of the Accellera?APIs were 1.1d and 1.2. However, Accellera moved the standard into the IEEE standardization process and the latest version is not owned by Accellera but IEEE, where it is IEEE 1800.2-2020. So the three latest versions of the API are have the somewhat confusing version numbers of 1.1d, 1.2, 1800.2 (which make their appearance many times in this post).
There was a similar Birds of a Feather meeting at DVCon 2021,?which?mostly consisted of users complaining to the working group. As the abstract for this year's session put it:
At the UVM Birds of a Feather meeting at DVCon U.S. 2021, the Accellera UVM Working Group heard from users how backward compatibility issues held back migration to the latest library. The Working Group is preparing to release a new library version (targeted for summer 2022) that reduces these issues greatly. At this meeting, the Working Group will present the expectations for this library, including the few remaining situations that may require user code updates, to again get feedback from the user community. There should also be time remaining for an open Q&A. Attendance to the Birds of a Feather is free, but registration through DVCon is required to access the platform.
The takeaway from last year was that:
领英推è
- The majority of users had not updated to an 1800.2 library release
- The main reason was lack of backward compatibility (old code would not compile against the new APIs)
- Secondarily, there was lack of a strong reason to make the investment to make the move
So between DVCon 2021 and DVCon 2022, the UVM WG has tried to address these two issues. I'm going to report on what Mark said, but I should emphasize that I am not a professional user of UVM (or even an amateur). There is a fair bit of detail he went into later in his presentation, I'll put that at the end of this post. It doesn't mean a lot to me but if you are a hands-on UVM user wanting to make the transition to 1800.2 then you should probably look into those details or you might trip over a boulder.
The biggest change is philosophical. The WG decided to change the philosophy on obsolete API interfaces from deprecating and eventually removing, to keeping the old functionality working, but no longer document it. That way existing users don't run into issues, but newly created code will only use the current interfaces. So using an out-of-date interface goes from creating a compiler error to compiling fine and requiring a 3rd party Linter to create a report on which old interfaces it would be a good idea to update and remove.