Verification Academy

Search form

My Account Menu

  • Register
  • Log In
  • Topics
  • Courses
  • Forums
  • Patterns Library
  • Cookbooks
  • Events
  • More
  • All Topics
    The Verification Academy offers users multiple entry points to find the information they need. One of these entry points is through Topic collections. These topics are industry standards that all design and verification engineers should recognize. While we continue to add new topics, users are encourage to further refine collection information to meet their specific interests.

    • Languages & Standards

      • Portable Test and Stimulus
      • Functional Safety
      • Design & Verification Languages

    • Methodologies

      • UVM - Universal Verification Methodology
      • FPGA Verification
      • Coverage

    • Techniques & Tools

      • Verification IP
      • Simulation-Based Techniques
      • Planning, Measurement, and Analysis
      • Formal-Based Techniques
      • Debug
      • Acceleration
  • All Courses
    The Verification Academy is organized into a collection of free online courses, focusing on various key aspects of advanced functional verification. Each course consists of multiple sessions—allowing the participant to pick and choose specific topics of interest, as well as revisit any specific topics for future reference. After completing a specific course, the participant should be armed with enough knowledge to then understand the necessary steps required for maturing their own organization’s skills and infrastructure on the specific topic of interest. The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization’s processes so that you can then reap the benefits that advanced functional verification offers.

    • Universal Verification Methodology (UVM)

      • UVMF - One Bite at a Time
      • Introduction to UVM
      • Basic UVM
      • UVM Debug
      • Advanced UVM
      • UVM Connect

    • Featured Courses

      • Portable Stimulus Basics
      • Introduction to DO-254
      • SystemVerilog OOP for UVM Verification
      • Power Aware Verification
      • Power Aware CDC Verification
      • Assertion-Based Verification
      • Metrics in SoC Verification

    • Additional Courses

      • Clock-Domain Crossing Verification
      • An Introduction to Unit Testing with SVUnit
      • Evolving FPGA Verification Capabilities
      • SystemVerilog Testbench Acceleration
      • Testbench Co-Emulation: SystemC & TLM-2.0
      • Verification Planning and Management
      • VHDL-2008 Why It Matters

    • Formal-Based Techniques

      • Formal Assertion-Based Verification
      • Formal Coverage
      • Formal-Based Technology: Automatic Formal Solutions
      • Getting Started with Formal-Based Technology
      • Handling Inconclusive Assertions in Formal Verification
      • Sequential Logic Equivalence Checking

    • Analog/Mixed Signal

      • AMS Design Configuration Schemes
      • Improve AMS Verification Performance
      • Improve AMS Verification Quality
  • All Forum Topics
    The Verification Community is eager to answer your UVM, SystemVerilog and Coverage related questions. We encourage you to take an active role in the Forums by answering and commenting to any questions that you are able to.

    • UVM Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • UVM Forum

    • SystemVerilog Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • SystemVerilog Forum

    • Coverage Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • Coverage Forum

    • Additional Forums

      • Announcements
      • Downloads
      • AMS Forum
      • OVM Forum
  • Patterns Library
    The Verification Academy Patterns Library contains a collection of solutions to many of today's verification problems. The patterns contained in the library span across the entire domain of verification (i.e., from specification to methodology to implementation—and across multiple verification engines such as formal, simulation, and emulation).

    • Implementation Patterns

      • Environment Patterns
      • Stimulus Patterns
      • Analysis Patterns
      • All Implementation Patterns

    • Specification Patterns

      • Occurrence Property Patterns
      • Order Property Patterns
      • All Specification Patterns

    • Pattern Resources

      • Start Here - Patterns Library Overview
      • Whitepaper - Taking Reuse to the Next Level
      • Verification Horizon - The Verification Academy Patterns Library
      • Contribute a Pattern to the Library
  • All Cookbooks
    Find all the methodology you need in this comprehensive and vast collection. The UVM and Coverage Cookbooks contain dozens of informative, executable articles covering all aspects of UVM and Coverage.

    • UVM Cookbook

      • UVM Basics
      • Testbench Architecture
      • DUT-Testbench Connections
      • Configuring a Test Environment
      • Analysis Components & Techniques
      • End Of Test Mechanisms
      • Sequences
      • The UVM Messaging System
      • Other Stimulus Techniques
      • Register Abstraction Layer
      • Testbench Acceleration through Co-Emulation
      • Debug of SV and UVM
      • UVM Connect - SV-SystemC interoperability
      • UVM Versions and Compatibility
      • UVM Cookbook

    • Coding Guidelines & Deployment

      • Code Examples
      • UVM Verification Component
      • Package/Organization
      • Questa/Compiling UVM
      • SystemVerilog Guidelines
      • SystemVerilog Performance Guidelines
      • UVM Guidelines
      • UVM Performance Guidelines

    • Coverage Cookbook

      • Introduction
      • What is Coverage?
      • Kinds of Coverage
      • Specification to Testplan
      • Testplan to Functional Coverage
      • Bus Protocol Coverage
      • Block Level Coverage
      • Datapath Coverage
      • SoC Coverage Example
      • Requirements Writing Guidelines
      • Coverage Cookbook
  • All Events
    No one argues that the challenges of verification are growing exponentially. What is needed to meet these challenges are tools, methodologies and processes that can help you transform your verification environment. These recorded seminars from Verification Academy trainers and users provide examples for adoption of new technologies and how to evolve your verification process.

    • Upcoming & Featured Events

      • DAC - Academy Booth #617 | June 3rd - 5th | Las Vegas
      • Low Power Verification Forum
      • Portable Simulus
      • Events Calendar

    • On Demand Seminars

      • UVM 1800.2 & Updated UVM Cookbook
      • Debug
      • FPGA Verification
      • Stimulus Generation
      • All On-Demand Seminars

    • Recording Archive

      • Portable Stimulus from IP to SoC
      • Wilson Research Group - 2018 Results
      • DAC & DVCon
      • UVM Forum
      • All Recordings

    • Mentor Training Center

      • SystemVerilog for Verification
      • SystemVerilog UVM
      • SystemVerilog UVM Advanced
      • Instructor-led Training

    • Mentor Learning Center

      • SystemVerilog Advanced OOP
      • UVM Transactions and Sequences
      • UVM Monitors and Agents
      • Functional Verification Library
  • About Verification Academy
    The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization's processes so that you can then reap the benefits that advanced functional verification offers.

    • Blog & News

      • Verification Horizons Blog
      • Academy News
      • Technical Resources

    • Verification Horizons Publication

      • Verification Horizons - February 2019
      • Verification Horizons - November 2018
      • Verification Horizons - June 2018
      • Verification Horizons - March 2018
      • Issue Archive

    • About Us

      • Verification Academy Overview
      • Subject Matter Experts
      • Contact Us

    • Training

      • Questa® & ModelSim®
      • SystemVerilog
      • Functional Verification Library
Ask a Question
UVM
  • Home /
  • Forums /
  • UVM /
  • is using UVM register layer worth the effort for small projects?

is using UVM register layer worth the effort for small projects?

UVM 4517
#UVM #RAL 31 Why using RAL 1 RAL register UVM 6
sarconi
sarconi
Full Access
6 posts
January 04, 2019 at 8:40 am

Let me start by clarifying the question. I do not mean it in general (I am sure it is very useful in certain projects, above all in advanced microelectronics companies), but for simpler projects with less need for reusability and complex functionalities. And where engineers have a certain knowledge of UVM but not (at least no experience with) the register layer

Imagine:
1. you only use 1 interface to send write and read config to the chip
2. the protocol is defined and will not change substantially
3. you want to use the register model to make your UVM agents behave accordingly
4. you want to build a scoreboard to check what has been written matches what is read out
5. you would also like the scoreboard to access internal registers of the DUT (backdoor style) for an additional check

Can the 3.-5. points above not be achieved by UVM classes w/o the need of the register layer abstraction? My main doubts:
- I guess 3. could be achieved with the configuration database (as I understand also the reg layer does)
- and 5. may be (uglier) obtained with an interface (list of registers) or better through VPI.

For such a "simple" target, can anybody see a strong argument to add on top of the configuration agent a higher level of abstraction, which then needs in addition the adapter and predictor and a knowledge of the UVM register layer syntax, etc. (i.e. learning curve) ?
I would really appreciate suggestions and comments from people with more experience on the field.

Many thanks in advance.

Replies

Log In to Reply
warnerrs
warnerrs
Full Access
57 posts
January 04, 2019 at 6:10 pm

In reply to sarconi:

Quote:
Can the 3.-5. points above not be achieved by UVM classes w/o the need of the register layer abstraction?

You are, of course, free to roll your own solution. However, you should plan out all the features you'll ultimately need before bravely marching to your own drum beat. You probably want to be sure it's actually less work to roll your own solution, than it is to follow the crowd.

That said, you are not alone in thinking uvm_reg is too big and complicated, and there are other alternatives that are already out there. I know nothing about the following, but it showed up in a quick google search. I plan to read it myself.

https://www.semiwiki.com/forum/content/5408-when-good-standards-get-lost-uvm-register-model.html

chr_sue
chr_sue
Full Access
2127 posts
January 05, 2019 at 12:31 am

In reply to sarconi:

Quote:

For such a "simple" target, can anybody see a strong argument to add on top of the configuration agent a higher level of abstraction, which then needs in addition the adapter and predictor and a knowledge of the UVM register layer syntax, etc. (i.e. learning curve) ?
I would really appreciate suggestions and comments from people with more experience on the field.

The key question is not a 'simple project'. It is how many configuration registers do you have. If you have only 1 to 5 configuration registers it might be an overkill to use the RAL. In any other case it is very useful to deal with the RAL.
To ease the implementation you should use an UVM Framework Generator like the EasierUVM Code Generator from Doulos (see here https://www.doulos.com/knowhow/sysverilog/uvm/). It is free of charge.

sarconi
sarconi
Full Access
6 posts
January 05, 2019 at 1:59 am

In reply to chr_sue:
Thank you both for your answers.
I would like to discuss just a bit more to further elaborate my opinion.
I went through the Doulos material on the RAL and do not need at this point the UVM code generator for the framework itself, since it's already there (and there is not RAL generator).
Then,

Quote:

The key question is not a 'simple project'. It is how many configuration registers do you have.

I am not sure why is the number of register that matters. Certainly, making a register model generation will need some scripting based on the list of registers. If the generated code is RAL or UVM classes I do not see much difference.

What I can see RAL asks in addition is to have a least 2 levels of register blocks (with maps/submaps) and build and connect adapter and predictor block (already where to put the predictor is not obvious, seems to be possible in multiple places). Unless you are looking for a lot of reusability or multiple interfaces configuring the chip, this seems like over-complicating it to me.

Turning the question around, could you anticipate for which aspects I would regret choosing a non-RAL approach?

chr_sue
chr_sue
Full Access
2127 posts
January 05, 2019 at 4:33 am

In reply to sarconi:

What we have to differentiate is 2 things:
(1) the UVM register model. This has to be created by a register model generator. The simulator providers are delivering such generators. It is not recommended and useful to do this manually.
(2) the integration of an existing rejister model in to a UVM environment. This is what the UVM Framework Generators are providing.

warnerrs
warnerrs
Full Access
57 posts
January 05, 2019 at 5:18 pm

In reply to sarconi:

Quote:
What I can see RAL asks in addition is to have a least 2 levels of register blocks (with maps/submaps) and build and connect adapter and predictor block (already where to put the predictor is not obvious, seems to be possible in multiple places). Unless you are looking for a lot of reusability or multiple interfaces configuring the chip, this seems like over-complicating it to me.

The mechanism to connect an adapter to the map is very simple, and regardless of your solution you'll have something that links your model to the interface driving the transactions. In this case, this is that thing.

If you limit yourself to making all register accesses through the register model, you can skip the predictor and just enable auto prediction ( uvm_reg_map::set_auto_predict(1) ); The predictor basically is there to update the mirror if a register access originates from somewhere other than the register model.

With regard to the hierarchy of map objects, in practice they are not a burden, as they are generated and connected by a tool.

© Mentor, a Siemens Business, All rights reserved www.mentor.com

Footer Menu

  • Sitemap
  • Terms & Conditions
  • Verification Horizons Blog
  • LinkedIn Group
SiteLock