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

      • RISC-V Design - Webinar
      • Exploring Formal Coverage
      • Processor Customization
      • 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 - July 2023
      • Verification Horizons - March 2023
      • Verification Horizons - December 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
Ask a Question
UVM
  • Home
  • Forums
  • UVM
  • How does uvm_component go to Clean-up phases from Run_phases?

How does uvm_component go to Clean-up phases from Run_phases?

UVM 6953
uvm_component 9 #run_phase 6 phase_raise_objection 3
dv_lee86
dv_lee86
Full Access
6 posts
November 30, 2022 at 12:59 am

Hi,

From what I've understood so far, uvm_components have each phase so that all objects are able to go to the next phase when all the same phase of every uvm_component objects are finished.
If so, all uvm_component should finish its own run_phase to go to the next phase. All uvm_components eventually complete all run_phase. Then why do we need to have phase.raise_objection & phase.drop_objection?
Can you help me where I misunderstand..?

Thank you,
Seunghyun Lee

Replies

Log In to Reply
cgales
cgales
Forum Moderator
2099 posts
November 30, 2022 at 5:39 am

In reply to dv_lee86:

The build phases and cleanup phases are implemented as functions, so they are all expected to complete in 0 time.

The run phases will consume time, so the UVM scheduler will fork these tasks in parallel. After forking the tasks, the UVM scheduler uses the objection mechanism to determine what tasks are still actively generating stimulus. When the stimulus tasks are finished and drop their objections, it will then kill all the remaining tasks that were forked. This mechanism allows drivers/monitors to execute in forever loops since they have no knowledge of when to finish.

dv_lee86
dv_lee86
Full Access
6 posts
December 01, 2022 at 12:30 am

In reply to cgales:

Thank you for reply.
I am still confused and I have two questions.

1) If no ones raise phase.raise_objection explicitly, test may finish right after starting run_phase?
2) From what I understood, All the same phase state should be completed to go to the next phase state. In run_phase state, some components which could not complete run_phase because of no raise_objection can go to the next phase state?
For example, there are two objects which are uvm_components.
In run_phase, test should not be finished until comp1 do drop_objection. After comp1 drop_objection, can comp1 go to check_phase, even if comp2 could not finish comp2 run_phase?

If so, it's conflicted with my thought that all the uvm components always do the same phase at the same time and should complete the previous phase to go to the next phase. It's conflicted with my thought because only uvm_component with raise/drop_objection seem to be able to finish. And only those which have finished can go to the next phase such as check_phase, and report_phase.
Please correct me.

//////////////////////////////////////////////////

class comp1
...
task run_phase
phase.raise_objection
...
phase.drop_objection
 
endtask: run_phase
 
task check_phase
...
endtask: check_phase
//////////////////////////////////////////////////
class comp2 
task run_phase
// no phase.raise_objection / drop_objection
 
endtask: run_phase
 
task check_phase
...
endtask: check_phase
//////////////////////////////////////////////////

Thank you,
Seunghyun Lee

Solution

Solution

cgales
cgales
Forum Moderator
2099 posts
December 01, 2022 at 5:49 am

In reply to dv_lee86:

The UVM scheduler will start the same phase of each component at the same time.

For a time consuming phase, the scheduler will wait for all objections to be dropped. When all objections are dropped, any additional tasks which are still running will be killed. In the case where no component raises an objection, the phase will immediately be terminated and the next phase will start. This can result in tests immediately finishing in 0 time.

In your example, the run_phase in comp1 and comp2 are forked. Since comp1 raises an objection, the scheduler will wait for the objection to be dropped. When this happens, since there are no outstanding objections, the run_phase of comp2 will be killed. The scheduler will then proceed to the next phase.

A component can't start a phase on its own. The execution of phases is controlled by the scheduler.

amir_sharfu
amir_sharfu
Full Access
9 posts
December 01, 2022 at 8:17 am


uvm_component divided into three phases
1. Build phases
2. Run phases
3. Clean-up phases

- Build phases and run phases start simulation at 0 time unit and then clean up phases start.
- Build phases and clean up phases are function and run-phases will time consuming...
- Let build start at 0 time and end also,
run_phase start at 0 time unit but it take some time to complete lets take (alpha)
clean-up phase start (alpha time) once run phases over, and then execute all the function like extract, check, report and final...

All these process start when we invoke run_test() or unm_root...

dave_59
dave_59
Forum Moderator
11289 posts
December 01, 2022 at 12:57 pm

In reply to dv_lee86:

Here is a simplified example showing how the UVM executes each phase (without objections)

class Component;
  string m_name;
  Component m_parent;
  static Component list[$];
  function new(string name, Component parent);
    m_name = name;
    m_parent = parent;
    list.push_back(this);
  endfunction
  function string get_fullname;
    if (m_parent == null)
      return m_name;
    else
      return {m_parent.get_fullname(), "." , m_name};
  endfunction         
  virtual function void build_phase;
  endfunction 
  virtual task run_phase;
  endtask 
  virtual function void report_phase();
  endfunction 
endclass 
class A extends Component;
  function new(string name, Component parent);
      super.new(name,parent);
     $display("A Constructing: ", get_fullname);
   endfunction
   task run_phase;  
     #10  $display("Running   from ",get_fullname(),,$time);
   endtask
   function void report_phase;
          $display("Reporting from ",get_fullname(),,$time);
   endfunction
 
endclass 
class B extends Component;
  function new(string name, Component parent);
   super.new(name,parent);
   $display("B Constructing: ", get_fullname);
  endfunction
  A a;
  function void build_phase;
    a = new("a",this);
  endfunction
  task run_phase;  
    #20  $display("Running   from ",get_fullname(),,$time);
  endtask
endclass 
class Root extends Component;
  function new(string name, Component parent);
    super.new(name,parent);
    $display("env Constructing: ", get_fullname);
   endfunction
  A a;
  B b;
  function void build_phase;
    a = new("a",this);
    b = new("b",this);
  endfunction
  task run_test;
    // build_phase
    for(int item=0;item<list.size();item++)
      list[item].build_phase();
    // run_phase 
    foreach(list[item])
      fork
        int k = item;
        list[k].run_phase();
      join_none
    wait fork;
    // report phase
    foreach(list[item])
      list[item].report_phase();
      endtask
endclass
 
module top;
   Root root;
   initial begin
     root =new("root",null);
     root.run_test();
   end
endmodule

— Dave Rich, Verification Architect, Siemens EDA

dv_lee86
dv_lee86
Full Access
6 posts
December 01, 2022 at 6:18 pm

In reply to cgales:

Thank you all for kindly helping me understand. I did not know that scheduler do wait in time-consuming phase.

Thank you,
Seunghyun Lee

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