Scribd
Upload
535 views

Uvm Faq

1. The build_phase() executes in a top-down manner to allow parents to construct children components. 2. Most other phases like run_phase(), main_phase() etc. execute in a bottom-up manner as the order does not matter for these phases. 3. The connect_phase() specifically executes in a bottom-up manner so that children can connect to parents before parents connect to each other. This ensures proper connectivity between all components.

Uploaded by

seemab
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
535 views

Uvm Faq

1. The build_phase() executes in a top-down manner to allow parents to construct children components. 2. Most other phases like run_phase(), main_phase() etc. execute in a bottom-up manner as the order does not matter for these phases. 3. The connect_phase() specifically executes in a bottom-up manner so that children can connect to parents before parents connect to each other. This ensures proper connectivity between all components.

Uploaded by

seemab
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

Saturday, 16 April 2016

UVM FAQ1

Explain about Virtual Sequence and virtual sequencer?


A virtual sequencer is a sequencer that is not connected to a driver itself, but contains handles for
sequencers in the test-bench hierarchy.
A sequence which controls stimulus generation across more than one sequencer, Usually the top
level of the sequence hierarchy. Virtual sequences do not need their own sequencer, as they do
not link directly to drivers.

Why Virtual Sequence and Virtual sequencer?


Consider a scenario of verifying a simple protocol; In this case, we can live with just one
sequencer sending the stimulus to the driver. The top-level test will use this sequencer to process
the sequences.
But when we are trying to integrate 2-4 block at Cluster level, at that time we surely want to
reuse block level scenarios (sequences) to verify cluster level scenarios. For example we are
integrating 2 blocks, so here two block level sequencers are driving two blocks. At top level test
we need to find a way to control these two sequencers.
This can be achieved by using Virtual Sequencer and Virtual Sequence.
Other way of doing it is to call sequences start method explicitly from top-level test by passing
sequencer.
But this is not a efficient way to do this. By doing this, we cannot reuse these cluster level
complex scenarios further to develop more complex scenarios at SoC level where multiple
Cluster level environments are integrated.
Ref: https://blogs.synopsys.com/vip-central/2015/03/31/virtual-sequences-in-uvm-why-how/

What is the difference between uvm_component and uvm_object?

OR

We already have uvm_object, why do we need uvm_component which is actually derived class
of uvm_object?
1) uvm_components are "static" in that they are created during build_phase() and persist
throughout the simulation.
uvm_objects are transient, such as transactions that are created when needed and disappear when
not used anymore.
2) There is an extra argument for "uvm_component - new" function for which we need to define
the parent class name. so, uvm_component is a part of uvm hierarchy while uvm_object does
not.
3) uvm_component has phases while uvm_object doesn't.
Difference between export and import:

Basically, both exports and imps provide the implementations of whatever methods your TLM
port requires. The difference is an export is an indirect connection to an implementation. It
normally used when there is component hierarchy involved.

Advantages of TLM over mailbox:


Let's say you have two components: A and B. Component A has a thread doing puts and
component B has a thread doing gets. They are both connected through a common mailbox
which means they both must declare handles to a matching mailbox type. This creates an
unwanted dependency. At some point, I might want some other component other than a mailbox
to connect to, like some kind of arbitrator. So I would have to modify the handles types in the
components.

What is the difference between early randomization and late randomization of sequences?
To send a sequence_item to a driver there are four steps that need to occur in sequence:
Step 1 Creation

Step 2 - Ready - start_item()

Step 3 Set (randomize or assign direct values to variables of sequence_item)

Step 4 - Go - finish_item()
Steps 2 and 3 could be done in any order. However, leaving the randomization of the
sequence_item until just before the finish_item() method allow the sequence_item to be
randomized according to conditions true at the time of generation. This is sometimes referred to
as late randomization.
The alternative approach is to generate the sequence_item before the start_item() call, in this
case the item is generated before it is necessarily clear how it is going to be used. This is referred
as early randomization.

What is the difference between creating an object using new() and create()?
create() is a factory method which construct an object. To override an object you need to
construct it using create(). If you use set_type_override before run then, factory replaces
constructed object with derived object (specified in override). If you use new() then you cant
override.
You should always use create() rather than using new() for classes registered with the factory.

What is the difference between sequence_item, sequence and sequencer with respect to UVM?
sequence_item:
A sequence item is an object that models a piece of information being transmitted between two
components (sometimes it's called a "transaction"). It can be can be directed, constrained
randomized or fully randomized.

sequence:
Sequences are objects whose body() method is used to generate sequence_items, optionally
randomize it and sent to the driver through sequencer.
UVM Sequences can be transient or persistent means it may drive stimulus for the duration of
the simulation, or anywhere in-between.
UVM Sequences are not part of the component hierarchy.

sequencer:
UVM Sequencer controls the flow of UVM Sequence Items (transactions) generated by one or
more UVM Sequences.
get_next_item(), item_done() is implemented in uvm_sequencer.
When multiple sequences are running in parallel, then sequencer is responsible for arbitrating
between the parallel sequences.
lock(), unlock(), grab(), ungrab() is implemented in uvm_sequencer.

sub-sequence:
sequences can call other sequences (via sequence.start()). A sequence that is started from another
sequence (as opposed to from a test) is called a sub-sequence.

Monday, 25 April 2016


UVM FAQ2

Why phasing is used? What are the different phases in uvm?


UVM Phases is used to control the behavior of simulation in a systematic way & execute in a sequential
ordered to avoid race condition. This could also be done in system verilog but manually.
Which phases of UVM are Top-Down?
build_phase() & final_phase() are Top-Down, rest all phases are Bottom-Up.

Which phases of UVM are task?


run_phase(),
pre_reset_phase(), reset_phase(), post_reset_phase(),
pre_configure_phase(), configure_phase(), post_configure_phase(),
pre_main_phase(), main_phase(), post_main_phase(),
pre_shutdown_phase(), shutdown_phase(), post_shutdown_phase()

How do uvm phases initiate?


Calling run_test() constructs the UVM environment root component and then initiates the UVM
phasing.

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

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. You need a constructed object to call its method.

The build_phase() is also executed top-down so that the parent can provide override setting that the
children will use when they execute their build_phase()

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

What is the order of execution of run_phase() ?

The run_phase() of each component is executed concurrently with no defined order you can depend on.

During the run_phase() is there something like super.run_phase(phase) called?

You only need to call super.method() if you are extending a class an need the functionality of the base
method. There is nothing inside the run_phase() of a uvm_component, so there is no need to call
super.run_phase() when extending from it.
You may want to call it when extending your classes from your base classes.

What is the difference between run_phase and main_phase in uvm_component?


Actually, you can start a sequence in any phase. It is more important to understand the
domain/scheduling relationships between the task based (i.e. runtime) phases.

UVM undergoes a number of pre-simulation phases (build, connect, end_of_elaboration,


start_of_simulation) that are all implemented with functions. Once those are completed, the task based
phases begin.

The standard includes two schedules.

One is simply the run_phase, which starts executing at time zero and continues until all
components have dropped their objections within the run_phase.
The other schedule contains twelve phases that execute parallel to the run phase. They are:
pre_reset, reset, post_reset, pre_config, config, post_config, pre_main, main, post_main,
pre_shutdown, shutdown, and post_shutdown. They execute in sequence.

Every component has the opportunity to define or not define tasks to execute these phases. A phase
starts only when all components in the previous phase have dropped their objections. A phase continues
to execute until all components have dropped their objections in the current phase.

Why connect_phase() is bottom-up?

You might also like