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.

However, this is not 100% effective since some changes beetween1.1d and 1800.2 are simply not compatible so it is not possible that both old and new code compiles correctly. These limited cases will require limited user edits (see the end of this post for that).

So currently the API is being updated to go back to 1.1d and add back everything that was deprecated since then. As I said above, there are a couple of reasons that a few aspects of the API cannot be handled this way:

• It is not possible to include the old API if it contradicts the 1800.2 language reference manual (LRM)
• It does not make sense to reintroduce a bug that was fixed

There were 62 issues identified by comparing the LRMs, the majority of which were fixed in the library. The remaining issues are documented today in the Github repo for the WG. These will eventually become release notes. In the pie chart, the yellow areas are where there are issues. These are actually very rare conditions and so it is not as "scary" as it looks since the yellow is still a significant piece of the pie. For details on this, see either the Github repo or the slides at the end of this post.

Another problem area is if users have modified older versions of UVM libraries. If these modifications are still required in 1800.2 then they will need to be pulled forward, which might be a significant effort.

The other issue apart from the lack of backward compatibility was the lack of a strong reason to migrate. There are two big motivations. The first is that each release has bug fixes. The latest upcoming release will have at least 13 more. Another big change is a substantial improvement, around 30%, in the performance for regular expression (regex) matching. This is a big drain on performance since it is used heavily.

The current status is:

• all API re-additions are in place, so it would be great if users can try this out
• some API re-addItions have not been fully functionally tested
• goal is to complete this library by DAC 2022

Mark had a request from the WG:

Please download the 2020-2.0 early adopter version. Compile with this instead of what you currently use. Post compile errors on the UVM forums. We will post pages and workarounds. If you get a successful compile we’d appreciate seeing the post.

Following the presentation, there was a Q&A. Some of the questions were deep in the weeds so I'm only going to discuss the more high-level ones.

Q: What about a tool to translate from one API to the current one?

A: We considered it but it is beyond the working group, needs to understand so much of what the user is trying to do.

Q: How about a flag to stop using deprecated APIs and make them compile-time errors?

A: I would agree with that.

Q: UVM 1.2 had online HTLM documentation but that is lost in IEEE. Can we have it back?

A: We decided not to put out HTML documentation that duplicates what is in the IEEE PDF, plus the copyright is owned by IEEE now so the legality is unclear.

Q: Can we get the IEEE to do it then?

A: They never have done in the past

Deep Dive Details

 

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.

.