Why is the build() phase in UVM executed in a Top - Down fashion and the other phases in Bottom - Up fashion?

UVM
1

Hello,
While going through UVM phases it is mentioned that Build phase is top down phase and other phases are bottom up phases.
So What is the reason for build phase is executing in top down fashion and other phases working in bottom up fashion?

Thanks in Advance.
Regards

2

It is very simple. The build phase has to be that way because the parent component’s build_phase constructs the child components. You couldn’t call the child’s build_phase before the parent’s build_phase because they the child objects haven’t been constructed yet. An you need a constructed object to call its method.

The ordering within the other phases should not matter, except you might want know that the top level’s report_phase comes last.

3

In reply to dave_59:

Hi dave,

could you please provide the following clarifications.

as the parent component is not aware of derived components properties that belong to only derived component. how it would be possible for parent class to construct the derived component.

as super.build is already present in build function of child , as per your inputs it has to be called by the object , is it done by the parent object.

I am new to the uvm. could you please provide clarifications.

4

In reply to srbeeram:

Generally, I avoid using the terms parent/child when talking about inheritance. I use parent/child when referring to a tree structure of individual objects. The uvm_component hierarchy is such a tree structure. It is separate from the inheritance hierarchy of classes.

5

In reply to dave_59:

Thanks dave. I got clarity now.

6

In reply to srbeeram:

Hi Dave,

If I have a uvm_config_db #(abc)::set in the build_phase in the env, and later on, I have another uvm_config_db #(abc)::set with different values in the build phase in the test case, would the latter(test case) override the one in the env?

Thanks!

7

In reply to nickbayshore:

I think last write wins at the same component hierarchy level.

You should be able to write a small testcase to verify.

8

In reply to dave_59:

Hi Dave,

I wrote some tests to try to understand the order. I added printed messages in both build_phases in the test case and the test env respectively. The one in the test case printed the message first, which makes sense as the test case is actually instantiate the test env (so top down for the build_phase). So my intention is if the test case has already had the m_abc set by config_db, then the test_env should not set m_abc any more. Therefore, I have the code something like this:

in the test case:
uvm_config_db#(int)::set(this, “m_env.m_uvc.m_virtual_sequencer”, “m_abc”, 123);

in the test env (ie. m_uvc):
if (!(uvm_config_db#(int)::get(this, “”,“m_virtual_sequencer”, m_abc))) begin
uvm_config_db#(int)::set(this, “m_virtual_sequencer”, “m_abc”, 456); —> however, this code is still being executed
end

However, looks like the set in the test env is still getting executed, do you see what’s the problem here?

Thanks!

9

In reply to nickbayshore:

How about showing a complete self-contained simple example of exactly what you are trying to do. Just showing 3 classes should be enough: test, env, and virtual sequencer.

10

In reply to dave_59:

I don’t really have much to show. The whole intention is just to use a config_db to pass down a setting that can take precedence from a test case (i.e. uvm_test where instantiates the uvm_env), otherwise use the one in the uvm_env.

Thanks!