UVM Topics

UVM PHASES :-
• Build Phase is from Top to Bottom approach.

• Connect Phase is from Bottom to Top approach.

• End of elaboration phase is Bottom to Top approach.

• Start Of Simulation Phase is from Bottom to Top approach.

• Run Phase is Parallel approach.

• Extract phase is bottom to top approach.

• Check Phase is from Bottom to Top approach.

• Report Phase is from Bottom to Top approach.

• Final phase is Top to Bottom approach.

Sub Phases in Run Phase:-
UVM MACROS :-
`uvm_object_utils: Used for object registration

`uvm_components_utils: Used for Component registration

 `uvm_info("MYINFO1", $sformatf("val: %0d", val), UVM_LOW)

• We will use get_name(), get_type_name(), get_full_name() in MYINFO1 place.

• get_name() will give object name

• get_type_name() will give class name

• get_full_name() will give complete path till the object.

 `uvm_warning("MYWARN1", "This is a warning")

 `uvm_error("MYERR", "This is an error")

 `uvm_fatal("MYFATAL", "A fatal error has occurred")

`uvm_do :
• `uvm_do(req) it replaces 3 steps of handshaking ( create object, start_item(req),
randomize() and finish_item() )

`uvm_do_with :
• `uvm_do_with(req,Constraint) it replaces 3 steps of handshaking (start_item(req),
randomize() and finish_item()) along with that here we will add inline constraint.

`uvm_do_on_with :
• `uvm_do_on_with(req, sequencer, constraint) it replaces 3 steps of handshaking
( start_item(req), randomize() and finish_item() )

`uvm_send :
• `uvm_send(req) it replaces 3 steps of handshaking (finish_item())
• Explicitily we need to create object, start item and randomize();
• Uvm send will only send the randomized data to the driver.
Handshake between sequence and Driver
Start _item
UVM TLM
TLM (Transaction Level Modelling)
• It is a transaction-level modeling
• Where we can send data/transactions from
one component to another component
• TLM is used for communication between two
components.
 Types of TLM
• TLM Interface
• Port
• Export
• Imp Port
• Analysis Port
• FIFO
 1. TLM Interface

• Blocking
• Non-blocking
 Blocking:-
• Put,
• Get and
• Peek methods

1. Put:- The put method is used to send the transaction to another component.
Ex:- Handle.put(transaction)

2. Get:- Get method is used to receive the transaction from another component.
Ex:- handle.get(transaction)

3. Peek:- peek method is used to receive the data

Ex:- handle.peek(transaction)

1. Difference between get and peek ?

• Peek:- Copies data from a producer without consuming it. The transaction is not removed from the tlm_fifo.
• Get:- Retrieves a transaction from other components and removes it from the FIFO
 Non-blocking:-

1. Try_put:- The try_put method is used to send the transaction to another component.
Ex:- Handle .try_put();

2. Can_put:- this method is used to check whether the other component is ready to accept the
transaction else zero.
Ex:- handle.can_put();

3. Try_get:- the try_get method is used to receive transactions from another component.
Ex:- handle.try_get();

4. Can_get:-this method is used to check whether the component is contain transaction/not

Ex:- handle.can_get();
 2. TLM Ports
• TLM port has unidirectional and bidirectional ports
• It will send the transactions
A port can be connected to
1.Port
2.Export
3.Imp port

Syntax:-
Unidirectional :- uvm_*_port #(T)
Bi-directional:- uvm_*_port #(req,resp)
Example of tlm port
 3. TLM Exports
• TLM exports have unidirectional and bidirectional
ports
• It will receive the data/transaction

Syntax:-
Unidirectional :- uvm_*_export #(T)
Bi-directional:- uvm_*_export #(req,resp)
Example of tlm export
 4. TLM Imp Ports
• The TLM imp port is used to receive the transaction at the destination
• TLM imp ports have unidirectional and bidirectional ports

Syntax:-
Unidirectional :- uvm_*_imp #(T)
Bi-directional:- uvm_*_imp #(req,resp)

Q.Difference between Export and imp port?

In TLM SV, both exports and imports provide implementations for the
methods required by a TLM port. The difference is that an export is an
indirect connection to an implementation
 5. TLM FIFO
1.Uvm_tlm_fifo# (T)
An analysis FIFO is unbounded size with a write method

2.Uvm_tlm_analysis_fifo# (T)
An analysis FIFO is unbounded size with a write method

Syntax:-
Uvm_tlm_analysis_fifo #(T)

Q.Differenc between the tlm_fifo and tlm_analysis_fifo?

• uvm_tlm_analysis_fifo would have inbuilt analysis ports
• uvm_tlm_analysis_fifo is extended from uvm_tlm_fifo itself, so should not differ
much
 6.Analysis port
• The uvm_analysis_port is a TLM-based class that provides a write
method for communication.
• TLM analysis port broadcasts transactions to one or multiple
components
• Single uvm_analysis_port can have a connection with uvm_analysis_imp
or uvm_analysis_export. No errors will be reported.
They are 3 different type
• uvm_analysis_port
• uvm_analysis_export
• uvm_analysis_imp

Analysis Ports Declaration:

uvm_analysis_port #(<trans_item>) analysis_port;
uvm_analysis_imp #(<trans_item>, <receiver_component>) analysis_imp;
uvm_analysis_export #(<trans_item>) analysis_export;
 Questions
Q. Difference between uvm_analyisis_port and uvm_tlm_ports?
• TLM Ports are supported only by one-to-one connection
• UVM Analysis port supports to one too many connections

Q. difference between the analysis export and analysis imp port?

uvm_analysis_imp - an input port of TLM (write can be implemented in this
component)
uvm_analysis_port - an output of TLM
uvm_analysis_export is used for hierarchical connections
Example of Analysis_port
Example of Analysis export
Example of Analysis imp port
Analysis port and export connections
 6.Different Connections
• Port ---port
• Port----export
• Port ----imp
• Export----export
• Export---imp
Port Export Imp port Analysis port
 Monitor
class monitor extends uvm_monitor;
`uvm_component_utils(monitor)
uvm_analysis_port #(seq_item) item_collect_port;

//declare of analysis port for multiple scoreboards

// uvm_analysis_port #(seq_item) item_collect_port1;
// uvm_analysis_port #(seq_item) item_collect_port2;
// uvm_analysis_port #(seq_item) item_collect_port3;
seq_item mon_item;

task run_phase (uvm_phase phase);

forever begin // Sample DUT information and translate into transaction
item_collect_port.write(mon_item);
end
endtask
Endclass
 Scoreboard
class scoreboard extends uvm_scoreboard;
`uvm_component_utils(scoreboard)
uvm_analysis_imp #(seq_item, scoreboard) item_collect_export;

//declare of analysis port for multiple monitors

// uvm_analysis_imp #(seq_item, scoreboard) item_collect_export1;
//uvm_analysis_imp #(seq_item, scoreboard) item_collect_export2;
//uvm_analysis_imp #(seq_item, scoreboard) item_collect_export3;

function new(string name = "scoreboard", uvm_component parent = null);

super.new(name, parent);
item_collect_export = new("item_collect_export", this);
endfunction
endclass
 Environment connection in the connect
phase
Connection of multiple monitors to single scoreboard
agt1.mon1.item_collect_port1.connect(sb.item_collect_export1);
agt2.mon2.item_collect_port2.connect(sb.item_collect_export2);
agt3.mon3.item_collect_port3.connect(sb.item_collect_export3);

Connection of single monitor to multiple scoreboard

agt.mon.item_collect_port1.connect(sb1.item_collect_export1);
agt.mon.item_collect_port2.connect(sb2.item_collect_export2);
agt.mon.item_collect_port3.connect(sb3.item_collect_export3);
UVM Callbacks
 Introduction
• The UVM Callbacks allow you to customize your verification environment
without modifying the base classes or components.
• A callback is a way to inject a new code in a file (in most cases it's a driver)
from a test case, without modifying the original file.
Callback macros
 Callback classes

Callback methods
 Steps to implement uvm_callback
1. Create a user-defined callback class that extends from the uvm_callback
class.

2. Add an empty callback method

3. The driver_cb callback class code:

 Cont…
3. Implement a callback method in the class which is extended from the
above user-defined class.

4. Register user-defined callback method using `uvm_register_cb in the component or object

where callbacks are called (In the below example, it is registered in the driver component).
 Cont..
5. Place callback hook i.e. calling callback method in the required
component or object using `uvm_do_callbacks macro

6. Driver component code:

Cont…
Cont…
Scoreboard
 Scoreboard types
• The UVM scoreboard is a component that checks the functionality of
the DUT.
• It receives transactions from the monitor using the analysis export for
checking purposes.

UVM Scoreboard types

Depending on design functionality scoreboards can be implemented in
two ways.
1. In-order scoreboard (FIFO)
2. Out-of-order scoreboard (LIFO)
 In-order Scoreboard
• The in-order scoreboard is useful for the design whose output order
is the same as driven stimuli.
• The comparator will compare the expected and actual output streams
in the same order.
• They will arrive independently. Hence, the evaluation must block until
both expected and actual transactions are present.

FIFO
Input Data Output Data
3

2 2 1 0
3 2 1 0 3
1
00
 Out of Order Scoreboard
• The out-of-order scoreboard is useful for the design whose output
order is different from driven input stimuli.
• Based on the input stimuli reference model will generate the expected
outcome of DUT and the actual output is expected to come in any order

• Handles transactions arriving in any order, independent of the request

sequence.
• Utilizes a hash table for efficient matching of received responses with
expected transactions.
• Maintains an Actual Queue (initially empty) to temporarily store out-
of-order responses.
• The scoreboard checks the Actual Queue for duplicates, then the hash
table for expected transactions based on response IDs.
• Offers flexibility for scenarios where the DUT might process requests
out of order.
 Cont….

Index Associative array

3 1

2 3

1 2
0 0