| Authors: Rich Edelman - Mentor, A Siemens BusinessMoses Satyasekaran - Mentor, A Siemens Business Introduction: This paper is part history and background; part performance analysis; part UVM development archeology; part testbench architecture; and part pining for a future of stability and simplification for verification engineers. It shares tips for creating a useful report server, or replacing the factory, or installing a new core service. It also discusses improvements to debug for the configuration database that continue to be needed after many years. There is no surprise ending. The UVM is here to stay, being used widely for verification productivity improvements world-wide. And the UVM-IEEE is the latest release. The UVM IEEE: The UVM IEEE is substantially the same as UVM 1.2 [6] and UVM 1.1d [5], with just enough backward incompatibilities to keep things interesting. The released code unpacks with a name like ‘uvm-core-1800.2-2017-1.0’. I’d prefer uvm-1800.2-2017-1.0 or better and in keeping with uvm-1.1d and uvm-1.2 - uvm-ieee-1.0. In any case, in this paper the release will be called ‘UVM IEEE’. What’s New in UVM IEEE? The README.md file in the release has notes about changes. Comment lines were added throughout the UVM IEEE source code, annotating what is part of the standard, what might be considered for inclusion in the future, and what is in the Accellera implementation (@uvm-ieee, @uvm-contrib and @uvm-accellera, respectively). Certain UVM 1.2 APIs were deprecated. They are still available behind a switch, but will be removed in the next release. Any code that was previously deprecated in UVM 1.2 has been removed. There are some short migration instructions (my emphasis, formatting and typo corrections): Compile/Run using a UVM1.2 library with `UVM_NO_DEPRECATED` defined This will ensure that your code runs with UVM 1.2 which was a baseline for the IEEE 1800.2 standard developmentCompile/Run using this library with `UVM_ENABLE_DEPRECATED_API` defined This step helps identify the areas where your code may need modifications to comply with the standardCompile/Run using this library without `UVM_ENABLE_DEPRECATED_API` defined. Removing the `define ensures that only the 1800.2 API documented in the standard, along with any non-deprecated Accellera supplied API, is usedAny new compile failures are the result of deprecated 1.2 APIs The migration instructions sound simple, but experience suggests otherwise. A testbench which used many of the detailed APIs and tricky techniques in uvm-1.1d or uvm-1.2 will have problems migrating. They are simple problems usually, requiring less than a week to manage. The suggestion for the future remains – use only as much of the UVM as needed, and no more. In that way, changes are less trouble in later releases. The benchmark example in this paper runs unchanged on all three UVM versions (uvm-1.1d, uvm-1.2 and UVM-IEEE). It is simple, but yet a complete testbench. The DEVIATIONS.md file in the release has notes about issues that were found in the UVM IEEE LRM which were corrected by writing different (non-compliant) code in the UVM IEEE implementation. These are items to be changed in the LRM for a future release. For example, the LRM defined do_kill() as non-virtual. It should be virtual. The LRM defined unlock() and ungrab() as tasks. They should be functions. There are a total of 10 of these kind of items listed. The docs directory in the release contains a surprisingly small HTML “UVM 1800.2-2017 Class Reference Manual”. (uvm-core-1800.2-2017-1.0/docs/html/index.html) The src directory in the release contains the usual contents. It will be familiar to any UVM user. View & Download: Read the entire UVM IEEE Shiny Object technical paper. | |