Welcome to the Demo Tour of the UVM/OVM Cookbook on Mentor's Verification Academy.
This is an overview of the pages in the cookbook - there are hundreds of articles that are available to you,
including real example code on the article pages and for offline download, once you register for full access.

Navigation:

Previous Page in Tour: Tour/Testbench Tour/Cookbook Next Page in Tour: Tour/Connections

Introduction

Phasing is a major area of new functionality in the UVM. Accelera has introduced a number of new technologies:

1. An enhanced set of standard time consuming phases
2. The ability to jump backwards and forwards between phases
3. The ability to add user defined phases and to specify the relationships between them
4. The ability to define domains with different schedules

There are a number of articles in this section which describe our recommendations for using this technology. These include:

1. How to make your testbench phase aware
2. How to manage sequences in the context of phasing
3. How to design reusable transactors that work in the context of phasing
4. How to gradually migrate your OVM code to UVM so that it becomes phase aware

The Standard UVM Phases

In order to have a consistent testbench execution flow, the UVM uses phases to order the major steps that take place during simulation. There are three groups of phases, which are executed in the following order:

1. Build phases - where the testbench is configured and constructed
2. Run-time phases - where time is consumed in running the testcase on the testbench
3. Clean up phases - where the results of the testcase are collected and reported

The different phase groups are illustrated in the diagram. The uvm_component base class contains virtual methods which are called by each of the different phase methods and these are populated by the testbench component creator according to which phases the component participates in. Using the defined phases allows verification components to be developed in isolation, but still be interoperable since there is a common understanding of what should happen in each phase.

Starting UVM Phase Execution

To start a UVM testbench, the run_test() method has to be called from the static part of the testbench. It is usually called from within an initial block in the top level module of the testbench.

Calling run_test() constructs the UVM environment root component and then initiates the UVM phasing. The run_test() method can be passed a string argument to define the default type name of an uvm_component derived class which is used as the root node of the testbench hierarchy. However, the run_test() method checks for a command line plusarg called UVM_TESTNAME and uses that plusarg string to lookup a factory registered uvm_component, overriding any default type name. By convention, the root node will be derived from a uvm_test component, but it can be derived from any uvm_component. The root node defines the test case to be executed by specifying the configuration of the testbench components and the stimulus to be executed by them.

For instance, in order to specify the test component 'my_test' as the UVM testbench root class, the Questa command line would be:

vsim tb_top +UVM_TESTNAME=my_test

Phase Descriptions

The following section describes the purpose of each of the different UVM phases

Build Phases

The build phases are executed at the start of the UVM testbench simulation and their overall purpose is to construct, configure and connect the testbench component hierarchy.

All the build phase methods are functions and therefore execute in zero simulation time.

build

Once the UVM testbench root node component is constructed, the build phase starts to execute. It constructs the testbench component hiearchy from the top downwards. The construction of each component is deferred so that each layer in the component hierarchy can be configured by the level above. During the build phase uvm_components are indirectly constructed using the UVM factory.

connect

The connect phase is used to make TLM connections between components or to assign handles to testbench resources. It has to occur after the build method has put the testbench component hierarchy in place and works from the bottom of the hierachy upwards.

end_of_elaboration

The end_of_elaboration phase is used to make any final adjustments to the structure, configuration or connectivity of the testbench before simulation starts. Its implementation can assume that the testbench component hierarchy and inter-connectivity is in place. This phase executes bottom up.

Run Time Phases

The testbench stimulus is generated and executed during the run time phases which follow the build phases. After the start_of_simulation phase, the UVM executes the run phase and the phases pre_reset through to post_shutdown in parallel. The run phase was present in the OVM and is preserved to allow OVM components to be easily migrated to the UVM. It is also the phase that transactors will use. The other phases were added to the UVM to give finer run-time phase granularity for tests, scoreboards and other similar components. It is expected that most testbenches will only use reset, configure, main and shutdown and not their pre and post variants

start_of_simulation

The start_of_simulation phase is a function which occurs before the time consuming part of the test bench starts. It intended to be used for displaying banners; testbench topology; or configuration information. It is called in bottom up order

run

The run phase occurs after the start_of_simulation phase and is used for the stimulus generation and checking activities of the testbench. The run phase is implemented as a task, and all uvm_component run tasks are executed in parallel. Transactors such as drivers and monitors will nearly always use this phase.

pre_reset

The pre_reset phase starts at the same time as the run phase. Its purpose is to take care of any activity that should occur before reset, such as waiting for a power-good signal to go active. We do not anticipate much use for this phase.

reset

The reset phase is reserved for DUT or interface specific reset behaviour. For example, this phase would be used to generate a reset and to put an interface into its default state.

post_reset

The post_reset phase is intended for any activity required immediately following reset. This might include training or rate negotiation behaviour. We do not anticipate much use for this phase.

pre_configure

The pre_configure phase is intended for anything that is required to prepare for the DUT's configuration process after reset is completed, such as waiting for components (e.g. drivers) required for configuration to complete training and/or rate negotiation. It may also be used as a last chance to modify the information described by the test/environment to be uploaded to the DUT. We do not anticipate much use for this phase.

configure

The configure phase is used to program the DUT and any memories in the testbench so that it is ready for the start of the test case. It can also be used to set signals to a state ready for the test case start.

post_configure

The post_configure phase is used to wait for the effects of configuration to propagate through the DUT, or for it to reach a state where it is ready to start the main test stimulus. We do not anticipate much use for this phase.

pre_main

The pre_main phase is used to ensure that all required components are ready to start generating stimulus. We do not anticipate much use for this phase.

main

This is where the stimulus specified by the test case is generated and applied to the DUT. It completes when either all stimulus is exhausted or a timeout occurs. Most data throughput will be handled by sequences started in this phase.

post_main

This phase is used to take care of any finalization of the main phase. We do not anticipate much use for this phase.

pre_shutdown

This phase is a buffer for any DUT stimulus that needs to take place before the shutdown phase. We do not anticipate much use for this phase.

shutdown

The shutdown phase is used to ensure that the effects of the stimulus generated during the main phase have propagated through the DUT and that any resultant data has drained away. It might also be used to execute time consuming sequences that read status registers.

post_shutdown

Perform any final activities before exiting the active simulation phases. At the end of the post_shutdown phase, the UVM testbench execution process starts the clean up phases. We do not anticipate much use for this phase ( with the possible exception of some object-to-one code ).

Clean Up Phases

The clean up phases are used to extract information from scoreboards and functional coverage monitors to determine whether the test case has passed and/or reached its coverage goals. The clean up phases are implemented as functions and therefore take zero time to execute. They work from the bottom to the top of the component hiearchy.

extract

The extract phase is used to retrieve and process information from scoreboards and functional coverage monitors. This may include the calculation of statistical information used by the report phase. This phase is usually used by analysis components.

check

The check phase is used to check that the DUT behaved correctly and to identify any errors that may have occurred during the execution of the test bench. This phase is usually used by analysis components.

report

The report phase is used to display the results of the simulation or to write the results to file. This phase is usually used by analysis components.

final

The final phase is used to complete any other outstanding actions that the test bench has not already completed.