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

      • Static & Formal - Israel | May 31st
      • 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
Ask a Question
UVM
  • Home
  • Forums
  • UVM
  • Calling of build phase?

Calling of build phase?

UVM 6740
uvm 124 UVM_PHASE 11 build_phase 9
Rohan
Rohan
Forum Access
4 posts
October 21, 2014 at 11:35 pm

Hi Dave,
Who Calls the build phase of each components in UVM hierarchy?

Replies

Log In to Reply

Solution

Solution

tfitz
tfitz
Forum Moderator
467 posts
October 22, 2014 at 10:54 am

The build_phase() method for each component is called top-down by the UVM "root".
What actually happens is that run_test() causes the uvm_test object to be created, then it's build_phase() is called. The test's build_phase causes the uvm_env to be created, which adds it to the list. Once uvm_test.build_phase() returns, the UVM looks for any additional components, so it now sees the uvm_env. It calls the env's build_phase(), which creates agents, etc. This continues until all created components' build_phase() methods get called, then the UVM continues and calls connect_phase() for all components (bottom-up).

georgean
georgean
Full Access
31 posts
October 22, 2014 at 9:29 pm

In reply to tfitz:

Can you please explain how the connect_phase() is bottom-up ?

In uvm_test.connect_phase() - we have nothing to connect.
In uvm_env.connect_phase() - assume that we connect the input_monitor with scoreboard predictor and output_monitor with scoreboard comparator -

input_monitor.analysis_port.connect(predictor.analysis_export) 
output_collector.analysis_port.connect(comparator.analysis_export)

In uvm_agent.connect_phase() - we connect the driver to the sequencer
uvm_driver.seq_item_port.connect(uvm_sqr.seq_item_export);

In this case as the connect_phase() is called in the below order

1)uvm_test.connect_phase()
2)uvm_env.connect_phase() 
3)uvm_agent.connect_phase()

The first the (input_monitor gets connected to predictor) and then (output_collector gets connected to comparator)
Then later at last the driver gets connected to sequencer

So this connection look top-down. Please correct me

Thanks in advance

dave_59
dave_59
Forum Moderator
10869 posts
October 22, 2014 at 11:56 pm

In reply to georgean:

I have attached a small example that demonstrates the calling order for some of the UVM phases given a simple hierarchy. A better term would have been depth-first traversal instead of bottom-up.

Note that calling the connect() method is not the same as calling the connect_phase(). The connect() builds a database of connections to be made between components. The order that you call the connect() methods does not matter as long as both ends of the connection have been constructed before making the call, and all connect() calls have been made before the end of the connect_phase. Conceivably, you could call the connect() method during the build_phase() or constructor, as long as the other requirements are met.

Files 
top-down.sv.gz

— Dave Rich, Verification Architect, Siemens EDA

Rohan
Rohan
Forum Access
4 posts
October 27, 2014 at 10:12 pm

In reply to dave_59:

Thank you all.

ssubramaniam
ssubramaniam
Forum Access
14 posts
June 13, 2017 at 9:41 am

In reply to dave_59:

Hi Dave,

Can you please point me to source which explains the differences between connect() and connect_phase(). Also is there similar explanation for build and build_phase().

Thanks
Subramaniam

dave_59
dave_59
Forum Moderator
10869 posts
June 14, 2017 at 12:03 pm

In reply to ssubramaniam:

The UVM reference manual is your source. connect_phase() is a virtual method of uvm_component, and connect() is a method of uvm_port_base. They are two different methods of two different classes. The OVM was even more confusing because it use the same method name connect() in two different classes.

Sometimes, its difficult to keep all the method names unique, especially when different people have their hands many areas of the code.

— Dave Rich, Verification Architect, Siemens EDA

hoalu
hoalu
Full Access
1 post
August 01, 2018 at 1:15 am

In reply to tfitz:

Quote:
The build_phase() method for each component is called top-down by the UVM "root".
What actually happens is that run_test() causes the uvm_test object to be created, then it's build_phase() is called. The test's build_phase causes the uvm_env to be created, which adds it to the list. Once uvm_test.build_phase() returns, the UVM looks for any additional components, so it now sees the uvm_env. It calls the env's build_phase(), which creates agents, etc. This continues until all created components' build_phase() methods get called, then the UVM continues and calls connect_phase() for all components (bottom-up).

Hi tfitz,
Does the execution order of .build_phase() depend on the order the components were created?

// Parent component
function build_phase();
a = new();
b = new();
end build_phase();

UVM will execute a.build_phase() first, and then execute b.build_phase()

chr_sue
chr_sue
Full Access
3890 posts
August 01, 2018 at 4:10 am

In reply to hoalu:

The build_phase is a function, executed in 0 time. If a or b is constructed first doesn't matter and it might depend on th eimplementation in the simualator.

cuonghle
cuonghle
Full Access
305 posts
August 01, 2018 at 4:30 am

In reply to chr_sue:

Why does it depend on simulator? I think the order here is important and it being handled by UVM? In UVM, it traverses to build a, all sub components of a (topdown order of a tree) then b and all sub components of b.

Chris Le

chr_sue
chr_sue
Full Access
3890 posts
August 01, 2018 at 4:48 am

In reply to chris_le:

My understanding is different. Topdown means starting on the toplevel it goes down, creating all components on a certain level and the proceed going to the next level. Then it does not matter if 'a' iss constructed first or 'b'.

cuonghle
cuonghle
Full Access
305 posts
August 01, 2018 at 7:53 am

In reply to chr_sue:

No, UVM build component using "pre-order of a tree traversal" (top-down).

From the parent component F, it traverses to build in order: B, A, D, C, E, G, I, H component (source picture from wiki)

https://www.edaplayground.com/x/4mfv

Chris Le

pk_94
pk_94
Forum Access
74 posts
August 02, 2018 at 12:45 am

In reply to chr_sue:

I think it doesn't matter for the case when there are multiple instances to be created at the same level , so in the above given case whichever is created first (a or b) doesn't matter.

So for all same level in the hierarchy whichever is created fisrt doesn't matter .

tfitz
tfitz
Forum Moderator
467 posts
August 02, 2018 at 7:35 am

In reply to chris_le:

This is exactly why there is a separate connect_phase() in UVM. During build_phase(), the exact order of building doesn't matter. The point is that, starting with F in your diagram, its build_phase() method will create B and G. Note that these two uvm_components are effectively independent of each other at this point, so it doesn't matter in which order they are created. If you are depending on them being created in a particular order, then you're doing something wrong.
There won't be any useful information to be had from B or G until their build_phase() methods have been called, which will likely include some call(s) to the uvm_config_db to configure them. This is also why the uvm_config_db is a separate thing rather than trying to pass parameters directly down to a child component when it is created (there are other logistical reasons why this isn't a good idea). So, even if you wanted to, you couldn't get any useful information out of B until after its build_phase() method completes. Of course, any such information would already be known to F which would have set it in the config_db to begin with, so F could just as easily use the same information to configure G, so again it doesn't matter in which order B and G are created.
The same argument applies recursively down the tree. A and D are created by B.build_phase() and it doesn't matter in which order they are created. Note that I would be created by G.build_phase() at the "same level" as A and D, and all of them are independent.
After the build_phase completes and all components have been configured and created, we call connect_phase() which relies on components having been created so that the ports/exports exist so that they can be created.
Any last-minute tweeking required before main_phase() starts can be handled by end_of_elaboration_phase().

cuonghle
cuonghle
Full Access
305 posts
August 02, 2018 at 9:20 pm

In reply to tfitz:

Thanks for clarifying.
1. In fact, the parent component adds its children to associate-array by name, and the created order can be predictable:

class F extends uvm_component;
  B b_m;
  G g_m;
 
  virtual function void build_phase(uvm_phase phase);
    g_m = G::type_id::create("g_m", this);
    b_m = B::type_id::create("b_m", this);
  endfunction
endclass

Associate children array of F component always will be (even we created g_m before b_m):

uvm_component m_children[string] = {
 "b_m": b_m,
 "g_m": g_m
}

Everytime F component gets next child to process the build_phase, B component is always the first one according to the array above. After all children of B component complete, G will be processed.

2. I wanted to clarify the idea: "All components at the same level must be built before going to the next level". Actually, this idea is not correct, right? In my example, A, D and I component are same level (A, D are children of B; I is child of G), but I component will never be processed at the same time as A and D.

Chris Le

tfitz
tfitz
Forum Moderator
467 posts
August 03, 2018 at 6:31 am

In reply to chris_le:

The fact that your current UVM implementation creates components in a predictable order does not change the fact that you should NOT rely on components being created in any particular order. With the standardization of IEEE 1800.2, much of the internals of UVM ARE no longer dictated by the standard in order to give developers and vendors the opportunity to optimize UVM implementations.
The only thing you can rely on is that a parent will create it child(ren) in its build_phase() method, and the child(ren)'s build_phase() method will run sometime later, after completion of the parent's build_phase(). PERIOD.
If you do anything else, it might work now, but there is no guarantee that it will work with your next version of UVM. And if it doesn't work in the future, it will be because you broke the rules, not because the UVM implementation changed.
I can't say this strongly enough:
DO NOT ASSUME ANY ORDER TO THE EXECUTION OF THE BUILD_PHASE() METHODS OF ANY UVM COMPONENTS OTHER THAN THAT A PARENT'S BUILD_PHASE WILL COMPLETE BEFORE THE CHILD(REN)'S BUILD_PHASE GETS CALLED.

cuonghle
cuonghle
Full Access
305 posts
August 03, 2018 at 11:44 am

In reply to tfitz:
Hi Tom,
Noticed, thanks for detail explanation.

Chris Le

Shubhabrata
Shubhabrata
Forum Access
102 posts
September 21, 2022 at 3:43 am

In reply to dave_59:

Thank you so much for this example. I have few doubts about the code you shared with us.

import uvm_pkg::*;
`include "uvm_macros.svh"
class grandchild extends uvm_component;
`uvm_component_utils(grandchild)   
   function new(string name, uvm_component parent);
      super.new(name,parent);
      `uvm_info("new", "constructor",0);
   endfunction
   function void build_phase(uvm_phase phase);
      `uvm_info("build", "phase",0);
   endfunction 
   function void connect_phase(uvm_phase phase);
      `uvm_info("connect", "phase",0);
   endfunction 
   task run_phase(uvm_phase phase);
      `uvm_info("run", "phase",0);
   endtask 
   function void report_phase(uvm_phase phase);
      `uvm_info("report", "phase",0);
   endfunction 
endclass 
class child extends uvm_component;
   grandchild gc1,gc2;
   function new(string name, uvm_component parent);
      super.new(name,parent);
      `uvm_info("new", "constructor",0);
   endfunction
   function void build_phase(uvm_phase phase);
      `uvm_info("build", "phase",0);
      gc1 = grandchild::type_id::create("gc1",this);
      `uvm_info("build", "created gc1",0);
      gc2 = grandchild::type_id::create("gc2",this);
      `uvm_info("build", "created gc2",0);
   endfunction
   function void connect_phase(uvm_phase phase);
      `uvm_info("connect", "phase",0);
   endfunction
   task run_phase(uvm_phase phase);
      `uvm_info("run", "phase",0);
   endtask 
   function void report_phase(uvm_phase phase);
      `uvm_info("report", "phase",0);
   endfunction 
endclass
class env extends uvm_env;
   `uvm_component_utils(env)
   child c1,c2;
   function new(string name, uvm_component parent);
      super.new(name,parent);
      `uvm_info("new", "constructor",0);
   endfunction
   function void build_phase(uvm_phase phase);
      `uvm_info("build", "phase",0);
      c1 = new("c1",this);
      c2 = new("c2",this);
   endfunction
   function void connect_phase(uvm_phase phase);
      `uvm_info("connect", "phase",0);
   endfunction
   task run_phase(uvm_phase phase);
      `uvm_info("run", "phase",0);
   endtask
   function void report_phase(uvm_phase phase);
      `uvm_info("report", "phase",0);
   endfunction 
endclass : env
class test extends uvm_test;
   `uvm_component_utils(test);
   function new(string name, uvm_component parent);
      super.new(name,parent);
      `uvm_info("new", "constructor",0);
   endfunction
   env e;
   function void build_phase(uvm_phase phase);
      `uvm_info("build", "phase",0);
      e = new("e",this);
   endfunction
   function void report_phase(uvm_phase phase);
      uvm_component tmp=uvm_top.find("uvm_test_top.e");
      env e;
      $cast(e,uvm_top.find("uvm_test_top.e"));
      `uvm_info("report", "phase",0)
      e.print();
   endfunction // report_phase
endclass   
module top;
   env e2;
   initial begin
      e2 =new("e2",null);
      run_test("test");
   end
endmodule

1) Inside the test class, env class creation of objects has been done differently. I mean
we can use new, but should we not use the protocol; using
{ class_type::type_id::create(name of the object,this); }

2) Inside the top module an object of env class has been created. I didn't understand, why?

3)

function void report_phase(uvm_phase phase);
      uvm_component tmp=uvm_top.find("uvm_test_top.e");
      env e;
      $cast(e,uvm_top.find("uvm_test_top.e"));
      `uvm_info("report", "phase",0)
      e.print();
   endfunction // report_phase

Here when we were finding whether any object named e has been created or not we used the
path uvm_top.find("uvm_test_top.e") . Why didn't we use
uvm_test_top?find("uvm_test_top.e")? And also return type is uvm_component . Is the reason
as same as we know for the do_copy method having argument uvm_object i.e. implementation
of factory or something else?
dave_59
dave_59
Forum Moderator
10869 posts
September 21, 2022 at 12:32 pm

In reply to Shubhabrata:

  1. Yes, using create() instead of new() is the proper protocol. I was trying to be quick in typing.
  2. This was just a contrived hierarchy. You are allowed to create uvm_components outside the test hierarchy as long as you do it before leaving the build_phase.
  3. "uvm_test_top" is the component string name given to the instantiated "test". uvm_top is a variable that contains the uvm_root of all components with a null parent. In this case the uvm_test created by run_test("test") and the "e2" object are two trees under uvm_top. (uvm_top was actually deprecated in IEEE UVM 1800.2 and you now need to use uvm_root::get() instead)

— Dave Rich, Verification Architect, Siemens EDA

hsam
hsam
Full Access
46 posts
March 29, 2023 at 5:58 pm

A test extends a base test

both the test and the base test have a task reset_phase(uvm_phase phase)

1) base test is starting reset_sequence_1 in reset phase
2) main test extending base test is starting reset_sequence_2 in reset phase

after the main test is complete- which reset sequence has taken effect?

Are we allowed to have same phase( reset_phase in this example) in main test and the base test? How would the compile resolve sequence starts in such a scenario?

dave_59
dave_59
Forum Moderator
10869 posts
March 29, 2023 at 6:38 pm

In reply to hsam:

All UVM phases are defined as virtual methods. When run_test() eventually gets to calling the reset_phase of every created component, as with any virtual method, it calls the most derived method for that class object. So unless main::reset_phase calles super.reset_phase, reset_sequence_1 will not get started.

— Dave Rich, Verification Architect, Siemens EDA

hsam
hsam
Full Access
46 posts
March 29, 2023 at 6:48 pm

In reply to dave_59:

what will happen if the task reset_phase in base test is not declared as virtual but the main test has declared the task reset_phase as virtual?

dave_59
dave_59
Forum Moderator
10869 posts
March 29, 2023 at 10:12 pm

In reply to hsam:

Assuming your base_test is extended from uvm_test, which is extended from uvm_component, the reset_phase method (and all other UVM phases) are defined as virtual methods in the uvm_component base class. SystemVerilog rules say that once a method gets defined as virtual, it remains virtual in all other derived classes; the virtual keyword becomes optional.

— Dave Rich, Verification Architect, Siemens EDA

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