UVM – “stop hitting your brother” – coding guidelines
There are different kinds of recommendations, includ- ing: “Write code THIS way,” “Don’t use this class,” “Don’t write this kind of code,” and “Do use this class.”
UVM promised a perfect world where a common set of guidelines for testbenches and connected verification IP would make a compatible, simpler world. But UVM carries baggage from previous standards, such as OVM, VMM, eRM, and AVM. This paper describes situations where UVM provides multiple ways to solve a problem, explains the issues with certain approaches, recommends solutions, and describes the tradeoffs.
The authors follow the adage on giving guidance: it is better to tell someone what to do, than what not to do. If you tell a kid to stop hitting his brother, he might not know what to do instead. So first, always tell someone what to do, such as go outside and play. You can then tell what they already know.
Background
This paper provides style and coding recommendations. As with all such recommendations, there is no single right answer for everyone. Style is in the eye of the beholder. Coding recommendations usage depends on the willingness to suffer a certain pain level. For many years, a software coding recommendation was “no gotos”. This recommendation relieves a certain complexity and difficulty in understanding and debugging the software. Code with gotos was hard to read and hard to debug and often called “spaghetti code”. This recommendation is now baked into programming languages as most no longer include goto statements.
Hopefully some of these recommendations in this paper will become part of future versions of UVM. It is with this in mind and with this same spirit that the style and coding recommendations are listed below.