| Authors: Rich Edelman - Mentor GraphicsBhushan Safi - Mentor Graphics Introduction: The UVM Register package [2] has many features. These features include reading and writing register values, reading and writing register fields and register blocks. The register model keeps track of the expected value and can directly access the actual modeled register using "back-door access". Using the register model allows a testbench to be written that can check the behavior of registers and address maps. Additionally, the register model can be constrained and randomized to provide stimulus or configurations. It can also be "covered" with functional coverage. These are the main operations of any register package; model the expected and actual values; check address mapping; generate random stimulus; allow direct access; support functional coverage. The problem in the UVM Register package arises in the intricacies in the register layer source code. For uvm-1.1d, there are 26 files containing over 22,000 lines of source code. That represents 19% of the total number of files in the UVM, and 32% of the total number of lines of source code. Clearly the UVM Register package is a large part of the UVM. In the next release, uvm-1.2, the percentages are reduced by increasing the files and lines in the overall UVM, but the absolute number of files is still 26, and the lines of source code is still over 22,000 for the UVM Register package. In the uvm1.1d User Guide, the description of the UVM Register layer is 26% of the number of pages. The UVM Register package is a large part of the UVM, by file and line count. There are many detailed, complete tutorials, papers and discussions about UVM Registers, and their various capabilities. These include a detailed description of pros and cons to various quirky register implementation methods [3]; an interesting tutorial on register access routines and the register computing model [4]; various tutorials and UVM register scenarios [5] [6]; and discussions about field modeling [7] [8]. A Google search for "UVM Registers" will yield many high quality results discussing various UVM Register aspects. This community of support is excellent and a welcomed sight for new users. But, one of the reasons that this community has grown so large, and so necessary is exactly the issue with the UVM Register package. It is big. It is complex. It is powerful. This paper proposes a re-think. A reconsideration of the goals and objectives, along with the implementation decisions. It discusses basic register model requirements and a suggested implementation and conceptual model that completely eliminates the need for a register library class, and the accompanying VPI interface to directly access the hardware. View & Download: Login to view the Beyond UVM Registers - Better, Faster, Smarter technical paper. | |