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
      • UVM Framework
      • UVM Connect
      • FPGA Verification
      • Coverage
    • Techniques & Tools

      • Verification IQ
      • Verification IP
      • Static-Based Techniques
      • 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)

      • Introduction to UVM
      • UVM Basics
      • Advanced UVM
      • UVM Connect
      • UVM Debug
      • UVMF - One Bite at a Time
    • Featured Courses

      • Introduction to ISO 26262
      • Introduction to DO-254
      • Clock-Domain Crossing Verification
      • Portable Stimulus Basics
      • Power Aware CDC Verification
      • Power Aware Verification
      • SystemVerilog OOP for UVM Verification
    • Additional Courses

      • Assertion-Based Verification
      • An Introduction to Unit Testing with SVUnit
      • Evolving FPGA Verification Capabilities
      • Metrics in SoC Verification
      • 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-Based Technology: Automatic Formal Solutions
      • Formal Coverage
      • 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
      • 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 Horizons - 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.
    • Featured & On-Demand

      • VA Live - Multiple Dates & Locations
      • Interconnect Formal
      • Formal and the Next Normal
      • Formal Verification Made Easy
      • Data Independence and Non-Determinism
      • Exhaustive Scoreboarding
      • Visualizer Debug Environment
      • Webinar Calendar
    • On-Demand Library

      • SystemVerilog Assertions
      • Practical Flows for Continuous Integration
      • Continuous Integration
      • Questa Verification IQ
      • Avery & Siemens VIP
      • Protocol and Memory Interface Verification
      • HPC Protocols & Memories
      • Preparing for PCIe 6.0: Parts I & II
      • High Defect Coverage
      • SoC Design & Functional Safety Flow
      • Complex Safety Architectures
      • All On-Demand Recordings
    • Recording Archive

      • Lint vs Formal AutoCheck
      • FPGA Design Challenges
      • Design Solutions as a Sleep Aid
      • Fix FPGA Failures Faster
      • CDC and RDC Assist
      • The Dog ate my RTL
      • Questa Lint & CDC
      • Hierarchical CDC+RDC
      • Improving Initial RTL Quality
      • CDC Philosophy
      • Hardware Emulation Productivity
      • The Three Pillars of Intent-Focused Insight
      • All Webinar Topics
    • Conferences & WRG

      • 2022 Functional Verification Study
      • Improving Your SystemVerilog & UVM Skills
      • Automotive Functional Safety Forum
      • Aerospace & Defense Tech Day
      • Siemens EDA Functional Verification
      • Industry Data & Surveys
      • DVCon 2023
      • DVCon 2022
      • DVCon 2021
      • Osmosis 2022
      • All Conferences
    • Siemens EDA Learning Center

      • EDA Xcelerator Academy(Learning Services) Verification Training, Badging and Certification
      • View all Xcelerator Academy classes
  • 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 IQ
      • Verification Horizons Blog
      • Technical Resources
    • Verification Horizons Publication

      • Verification Horizons - March 2023
      • Verification Horizons - December 2022
      • Verification Horizons - July 2022
      • Issue Archive
    • About Us

      • Verification Academy Overview
      • Subject Matter Experts
      • Academy News
      • Contact Us
    • Training

      • Learning @OneGlance (PDF)
      • SystemVerilog & UVM Classes
      • Siemens EDA Classes
  • Home
  • Events
  • Improving Your SystemVerilog Language and UVM Methodology Skills
  • Stimulating Simulating: UVM Transactions Q&A

Stimulating Simulating: UVM Transactions Q&A

  • Introduction
  • Video
  • Q&A
  • Blog
  • Subject Matter Expert
Other sessions in this seminar:

Here's a collapsed set of questions asked during the live web seminar along with Chris's answers. If you don't see your question here, or need further clarification, you can always ask on the Verification Academy Forums.


Can you please elaborate why transaction is not extended from uvm_transaction instead extended from uvm_sequence_item?

The uvm_transaction class was not designed to be part of group of transactions. The class uvm_sequence_item has additional properties that keep track of where this item is inside a sequence.

Why should I not randomize the output variables in the transaction class?

Filling in the transaction’s output variables with random values, like “99”, does not help verify the design. When the transaction object is created, randomize the variables that represent the design inputs. Then the object can be sent to testbench's predictor (part of the scoreboard or reference model) which calculate the output values. For example, if you are modeling an ALU, the inputs might be “ADD 2, 2”. The testbench predicts that the design’s output is “4”. Now you can compare this expected output to the actual design output.

When extending from a base uvm_sequence_item do you need to have all of your signals in the base class? Can you add additional signals in the extended class or will that cause issues with do_copy/do_compare?

Build your transaction classes in layers, and divide them up like the protocol layers. The base class might have just the basic signals. Extend the class for higher levels of protocol, adding signals as needed. Also extend these classes to add new functionality such as constraints, and other members.

What are the methods to copy if an object has object handles?

The copy() method performs a deep copy. Either you implement this with a do_copy() or the field macros. I did not show a deep do_copy() that worked with handles as there was not enough time.

Why '==='?

When you compare two values in SystemVerilog, always use the case equality operator, ===, to correctly handle X and Z bits. This way you don't have to try to remember if the properties are 2-state or 4-state - let the compiler figure that out.

If bit type signal, why '==='?

Pick the most general compare operator, and use it for 2-state and 4-state types.

Has there been any improvement in the field macros? The comparison between using custom do_*methods vs the built-in field macros was done using ovm if I recall correctly.

Yes, original field macros, written for OVM, were much less efficient than hand written code. The UVM versions are much better. Only worry about efficiency if a code profile shows that these are causing problems.

Where do we use "record"?

With the record() method, you can save transactions for waveform display, or write to a file to log their values. The compare() and clone() methods are used far more often than record().

I've used sprint() inside a uvm_info macro to control the verbosity.

That follows my recommendation of using uvm_info for all messaging. You are right - sprint() and convert2string() are very similar here.

How do_copy will work for parametrized class?

The do_copy() method can use the parameters just like any other method in a parameterized class. This is true for parameterized values and parameterized types.

If we miss super.do.**, compilation/runtime error will be resulted or not

If you leave out a call to super.do*(), your code may not work correctly. It will compile and run without errors, but won't work correctly.

Any good reason to switch from VMM to UVM?

Availability of Verification IP is the top reason. Improving your resume is another. There are 10-100x more UVM users than VMM.

For do_copy , without $cast?

The methods do_copy() and do_compare are passed handles of type uvm_object. You can not access properties in your transaction with this base handle, and need to cast it to a handle of your transaction type. Just try it! Remember, a base handle can point to a derived object.

Why is mixing field macros and do methods not great?

If you mix the two styles for a single hierarchy of transaction classes, you may get unexpected effects. The most notable is that the two print styles don't blend together. Try it and see.

Can we get parent object handle name inside the uvm_sequence_item ? Like if we want to print the parent of the transaction for debug?

Yes, there is a get_parent_sequence() in the uvm_sequence_item class.

Isn't it nice to have logic [2:0] input_field instead of bit [2:0] input_field. This way, design can be excersized by giving "x" inputs too to check if "x" propogation happens inside design or not.

Yes, you could inject X values. However the simulator's X-Prop extensions might be a better approach.

Chris, you mentioned using rand bit for tx_item i/p properties. Any downsides of using "rand logic" instead?

In general, randomization only produces 2-state values, so why use a 4-state type? It won't hurt, but logic is the wrong type for the job. Additionally, it will run a tiny bit slower, and take a tiny bit more memory.

If you have a bus that has SOP, EOP, data, valid, etc... Would you create a transaction for each step? (SOP, data, data, ..., EOP)? Or one transaction that's a queue of data bytes, and have the driver auto add the SOP and EOP flags? What about CRCs (both valid and invalid)?

Take a step back and think about this from an OOP view. Does it make sense to have a transaction with just a single byte? Are there operations that you want to perform on the byte-level transactions, or are you more focused on the entire stream?

If my trans has over 100 variables, what is the best way to print ? for ex: If I want tabular print then uvm_printer can have it , right? what should be the proper approach?

What are you really trying to do? If you use the field macros, uvm_printer formats properties for printing. I always used the default formatting, but with fewer properties. When I use the do methods, I never use uvm_printer.

We're using field macros in our TB and want to improve performance, is it possible to (somehow) measure/stimate the performance gain if we move to do_* style?

Use the code profiler to find the actual bottlenecks in your simulation. It could be field macros, or the uvm_config_db, or maybe even the RTL.

How to randomize variables without using rand function?

I assume you mean class-based constrained randomization with the randomize() method. There are multiple way's to generate random values in SystemVerilog, why would you want to avoid the most powerful and widely supported approach?

Any example, where we need to write separate compare methods out of transaction class?

You seem to be asking if you ever need to write a compare method outside of a transaction class. In UVM, transactions are described with classes, so what would you be comparing? UVM components are never compared or copied.

Siemens Digital Industries Software

Siemens Digital Industries Software

#TodayMeetsTomorrow

Portfolio

  • Cloud
  • Mendix
  • Electronic Design Automation
  • MindSphere
  • Design, Manufacturing and PLM Software
  • View all Portfolio

Explore

  • Community
  • Blog
  • Online Store

Siemens

  • About Us
  • Careers
  • Events
  • News and Press
  • Customer Stories
  • Partners
  • Trust Center

Contact

  • VA - Contact Us
  • PLM - Contact Us
  • EDA - Contact Us
  • Worldwide Offices
  • Support Center
  • Give us Feedback
© Siemens 2023
Terms of Use Privacy Statement Cookie Statement DMCA