Today I attended Mentor’s webinar “UVM1.2 is Coming, So Be Prepared”, presented by Tom Fitzpatrick. It was an overview of the changes that the new version of UVM will bring, and a number of recommendations on how to make the most of it. After having worked for nearly five months now with UVM 1.1, I was excited to know which were the new features and improvements that the next version of the verification standard would bring. Sadly, the presentation has been a huge dissapointment.
The original plan for the UVM 1.2 release was to just add a dozen enhancements to the previous version. But as no plan survives first contact with the enemy, the final changelog is way larger, with more than fifty changes to the standard. Half of them API changes, and a quarter of the total breaking backwards compatibility. I must say, I’m confortable with that, and I understand that sometimes, to allow a system to grow and evolve, it is necessary to break with what had been done in the past.
My problems with the presentation and the new revision started as soon as Fitzpatrick began to go in depth with thet new features UVM 1.2 includes. I will do a quick recap on several of the changes and Tom’s advice on them:
Feature: New UVM messaging macros (up to 20). Now messages can have multiple fields, with different actions per field.
Tom says: Using these macros causes a 20% performance penalty. Stick to UVM 1.1d macro set for performance and backwards compatibility.
Feature: New UVM transaction recording macros. Now not only `uvm_record_field is available, but also `uvm_record_int, `uvm_record_string, `uvm_record_time and `uvm_record_real.
Tom says: Using these macros causes a 65% performance penalty. Stick to UVM 1.1d macro set for performance and backwards compatibility.
Feature: Automatic raise and drop of objections before and after sequences can now be enabled.
Tom says: The use guidelines state that raising and dropping objections should be done in the test, not in the sequence, so it’s advisable not to use this feature.
Feature: Sequnces can now be started from the command line.
Tom says: Using this feature does not allow users to control the settings of the default sequene, so it’s advisable not to use this feature.
Feature: There are new functions for getting and setting the starting_phase object from a sequence.
Tom says: Since sequences shouldn’t raise objections, if you follow the use guidelines you will not need to use this feature.
Feature: VHDL backdoor support for registers
Tom says: OK if you must use VHDL, but I prefer Verilog and SystemVerilog.
Feature: Ability to control the order of sequences when accessing a register results in multiple bus transactions.
Tom says: It is only for very advanced users and requires more investigation, so you probably won’t need to ever use it.
Feature: New command line flag to allow uvm_objects to not need a constructor.
Tom says: It is advisable to always use constructor names, so you shouldn’t use this feature.
Feature: It is possible now to undo a factory override.
Tom says: If you have to use this feature, it is almost for sure that you did something wrong in some other part of the code, so it should never be needed if you code following the use guidelines.
There are several more new features and things that UVM 1.2 allows now, but I think you already get the general feeling of the presentation. And yes, it was all on the same line as the list I just presented. So I wonder… What’s the point of spending three years developing a new version of your standard if all your recommendations are “Don’t use this”? Seriously, I don’t understand it.
So, for what I have seen until now, would I advise to migrate to UVM 1.2 taking into account that, as Fitzpatrick says, it is almost sure that it will involve some code rewriting to comply with the new API changes, and that none of the new features seems to be remotely good or advisable to be used? For me, at least, the answer is clearly no.