UVM Phases: end_of_elobration

[prashant.kaushik]

I referred couple of documents; cookbook, uvm 1.2 user guide, to know why end_of_elobration is required.

 

However, i could not find answers for 'why it is required' and more specifically 'Is it really required?'

 

Please feel free to give your inputs

 

-Prashant Kaushik

[italiya]

end_of_elaboration phase starts once build and connect phase is done. So it ensure the all components of the environment is built and connection among component is established. Possible usage of end_of_elaboration phase could be

1. Print the overall topology

2. Query the configuration through PLI/VPI mechanism for specific usage

3. Final chance to tweak the topology for specific scenario / test. 

 

I believe that it is not must and above mentioned stuff can be done in start_of_simulation or run phase. But using it, would ensure a cleaner separation and easy to understand, maintain code in longer run.

[ljepson74]

Regarding:

'Is it really required?'

 

I would not say that a phase is required and I would not say it is not required.

The uvm phases will be passed through in succession, as a simulation runs.

I would simply say "they will happen".   In a normal UVM flow, there is no way to make a phase not happen**.

 

I think the question you want to ask is whether you, a user, or a test/testbench, needs to use the end_of_elaboration_phase (or any phase).   The answer to that, is no.  If you do not specify a function or task for the specific phase (and raise an objection if necessary), it will simply pass through.

 

italiya listed some things that might be done in that phase, but as pointed out, could be done in other phases as well.***

 

uvm phases, for the most part, are artificial sections of time, to help developers organize code more consistently.

Silly, off-the-cuff analogy:
Everyone on this forum decides to run their lives a certain way, on a certain schedule.

6am-7am:    wake, eat_breakfast, empty_garbage
10am-11am:  go_to_work
11am-2pm:    
2pm-4pm:    cigar_break
9pm-10pm:   go_home, eat_dinner, sleep

When you visit italiya, you'll know that you can expect breakfast in the time "6am-7am".  You'll know the rules of his home.
Italiya could decide to eat_breakfast in the time "11am-2pm" instead, or to not eat_breakfast at all (like not using the end_of_elaboration_phase), and things will be fine, but it might cause confusion for his guests who expect the above schedule.

In verification the uvm phase guidelines should help us all more quickly understand each others' tests and testbenches.

Just as Italiya cannot go_to_work before wake, there are certain things in our testbenches that must happen in a certain order.  For example, we must build/instantiate our testbench parts, before we generate stimulus or do anything else.  The structuring of phases help us to keep that order. 

**Well, certainly one could choose to end a test in any phase, before all phases are completed, or to phase jump.  But, in a typical flow, all phases will happen.

 

***Besides time-consuming items being required to happen in the run_phase (or it's sub phases), and besides building of components before the run_phase (?), I am not sure what else is restricted to a certain phase or group of phases.   An important distinction that was never so clear to me when I started is that the run_phase and it's sub phases are tasks (which can consume time), the other phases are functions (which cannot consume time).

 

I'm prepared for clarifications/corrections from others, but that's my understanding.

 

 

//This forum tool seems to be adding interesting colors to this post based on my use of ' and formatting buttons.

[dave_59]

The original intent of the phases in the OVM was to help with the initialization and shutdown of a simulation. The OVM phases mimic what happens in other environments like SystemC. end_of_elaboration is after all the elements of your testbench are constructed, and start_of_simulation is the initialization of your testbench. The phases make good breaking points for debug and checkpoints for restoring.

 

The problem with phases in general is that unless you get everyone to universally agree on what goes in each phase, they lose their effectiveness.