UVM Notes

This article is to list down the most used constructions of UVM to my personal understanding.

UVM simulator steps

• VCS(Synopsys)
• IUS(Cadence)
• Questa(Mentor)

1. set $UVMHOME to instal dir of required UVM library

2. Use irun option -uvmhome to reference $UVMHOME

3. Use incdir to reference any included file directories

%irun -f run.f

run.f:

-uvmhome $UVMHOME

-incdir .../sv

.../sv/tb_pkg.sv

top.sv

top.sv:

module top();

    import uvm_pkg::*;

    import tb_pkg::*;

    initial begin

        //run test

        ...

    end

endmodule: top

Debugging case: 

when using 3 step compile on vcs, vlogan and elab must both add uvm_dpi.cc to actually compile the c. add the file in file list does not work. 

if using 1 step compile, then just need to include the file in filelist. 

UVM Directory Structure

contains two kinds of code:

UVM_ROOT UVM_TOP

Tips: (1) debug features

uvm_top.print_topology();  //advised to be called from end_of_elaboration_phase

=======================================

If you look into the uvm source code, run_test() task is actually a task defined in the class uvm_root. it's the implicit top-level and phase controller for all UVM components. the UVM automatically creates a single instance of <uvm_root> that users can access via the global (uvm_pkg-scope) variable uvm_top. 

• long time confusion solved: the run_test() called in top tb module is defined in uvm_globals.svh which actually calls the run_test() in uvm_root.
• uvm_test_top is not a variable in uvm_root, how can you access that with uvm_root?
• class uvm_root extends uvm_component
• const uvm_root uvm_top = uvm_root::get();
• uvm_top is the top-level component, and any component whose parent is specified as NULL becomes a child of uvm_top.
• uvm top manages the phasing for all components.
• set globally the report verbosity, log files, and actions(?).
• Because uvm_top is globally accessible (in uvm_pkg scope(?)), UVM's reporting mechanism is accessible from anywhere outside uvm_component, such as in modules and sequences.

UVM Configuration

1) uvm_config_db

• uvm_config_db#(int)::set(this, "env.agent", "is_active", UVM_PASSIVE);
• uvm_config_db#(int)::set(null, "uvm_test_top.env.agent", "is_active", UVM_PASSIVE);
• uvm_config_db#(int)::set(uvm_root::get(), "uvm_test_top.env.agent", "is_active", UVM_PASSIVE);//equivalent to using null
• uvm_config_db#(int)::set(null, "*.env.agent", "is_active", UVM_PASSIVE);
• uvm_config_db#(int)::set(null, "uvm_test_top.env*", "is_active", UVM_PASSIVE);
• Database must be type parameterized. this allows config db to be created for any standard or user-defined type; and allows better compile time checking.
• Methods are static
• Methods use a specific contxt argument, whi is usually this; unless the set is called from the top module, in which case it must be assigned to null
• syntax: static function void set(uvm_component cntxt, string inst_name, string field_name, ref T value)
• syntax: static function void get(uvm_component cntxt, string inst_name, string field_name, ref T value)
• get is only required when set is called from the top level module or outside the build phase
• syntax: static function bit exists(uvm_component cntxt, string inst_name, string field_name, bit spell_chk = 0)
• syntax: static task wait_modified(uvm_component cntxt, string inst_name, string field_name)
• inst_name may contain wildcards or regular expression syntax
• for object, interfaces or user-defined types, use uvc_config_db
• for run-time configuration, use uvc_config_db

2) a specialized cfg task is set_config_* for uvm_component class, where * can be int, string or object, depending on type of config property:

• config settings are automatically resolved in UVM build phase; that is because apply_config_settings() is executed in the build phase (when super.build_phase() is called in any uvm_component class). settings are applied only when match is found, if not found, field names will be unset, and mismatched configuration set's should be listed at end of simulation.
• syntax: virtual function void set_config_in (string inst_name, string field, bitstream_t value)
• inst_name is relative pathname to a specific component instance from the component where the method is called
• field is a string containing a config property name of the instance class
• set build options before calling super.build_phase; this is also why the parameters are strings, because the components and fields does not exist yet.
• set_config_int("env.agent", "is_active", UVM_PASSIVE);
• set_config_int("*", "recording_detail", 1);//default is 0, by enabling the recording details for every component, transactions can be viewed in the waveform window(?)
• the creation of the agent instance in the parent build_phase() triggers the execution of the build_phase() of the agent instance.
• config property must be automated in the component where declared (field registered)
• Config settings in higher scope take precedence over lower scopes.
• Config settings in the same scope conform to "last one in wins"

UVM Field Automation

#Non-array
1) `uvm_field_int (<field_name>, <flags>)
2) `uvm_field_object (<field_name>, <flags>)
3) `uvm_field_string (<field_name>, <flags>)
4) `uvm_field_event (<field_name>, <flags>)

#static Array:
1) `uvm_field_sarray_enum (<enum_type>, <field_name>, <flags>)
2) `uvm_field_sarray_int (<field_name>, <flags>)
3) `uvm_field_sarray_object (<field_name>, <flags>)
4) `uvm_field_sarray_string (<field_name>, <flags>)
#dynamic Array:
1) `uvm_field_array_enum (<enum_type>, <field_name>, <flags>)
2) `uvm_field_array_int (<field_name>, <flags>)
3) `uvm_field_array_object (<field_name>, <flags>)
4) `uvm_field_array_string (<field_name>, <flags>)
#dynamic Array:
1) `uvm_field_queue_enum (<enum_type>, <field_name>, <flags>)
2) `uvm_field_queue_int (<field_name>, <flags>)
3) `uvm_field_queue_object (<field_name>, <flags>)
4) `uvm_field_queue_string (<field_name>, <flags>)

#associative Array:
1) `uvm_field_aa_<d_type>_<ix_type>

#flags

UVM_NOVOMPARE

#the do_* functions are worth more discussion later. 

uvm_factory

b extends a, c extends a, override(a,c)

will b be affected?

Tips: (1) how to use factory debug features. 

uvm_factory::get().print(); //prints the uvm_factory details like registration and override. can be called from build phase, connect phase or mostly likely end_of_elaboration_phase. 

UVM Phasing

Tips:(1) phasing debug features (not very useful)

sim option +UVM_PHASE_TRACE

(2) objection debugging 

sim option +UVM_OBJECTION_TRACE

UVM_sequence

start_item()

finish_item()

get_response()

driver: 

seq_item_port.get_next_item(), 

seq_item_port.item_done(), 

seq_item_port. put(resp)

UVM_POOL

uvm_object_string_pool #(T)

pool.get(string) #get object by a name

Scoreboard

A scoreboard normally consists of 3 components of functions:

1) reference model/transfer function

     c++, systemC or systemverilog: a) existing C model; b) create model, not in collaboration with design team( duplication of errors)

2) Data Storage

     model output instant, DUT takes time to output. Need to store data (and synchronization)

    Queue: output data in same order as input order

    Associative Array: out of order output. Key unique and knonw for input and output. herefore, key is either: a) untransformed port of data, or b) can be generated from data

3) comparison/check logic

Scoreboard internals:
    update counter, tracking received, dropped, matched, and mismatched
    report_phase, print summary of statistics
    end of simulation: check scoreboard queues are empty

Scoreboard must create a new copy of received data item by cloning, before writing the cloned packet to the queue.

UVM TLM Communication bwtween Components

TLM concepts: Port and Imp
    Data Flow: producer create data, consumer consume data
            Producer ---data---> Cosumer
    Control Flow: Initiator sends request to Target
            Initiator ---request---> Target
    producer is initiator: write operation, also called push/put: e.g. analysis connections
    producer is target: read operation, also called pull/get

Port: TLM connection object for Initiator
Imp (implementation): TLM connection object for target.
Export:
symbols: square(port), circle(imp), triangle(export)
port.connect(Imp)
port.connect(Export)

TLM Analysis Interface
uvm_analysis_port #(data type) ap_out
ap_out = new("ap_out", this);

`uvm_analysis_imp_decl(_foo)
uvm_analysis_imp_foo #(data type) foo_in
`uvm_analysis_imp_decl(_bar)
uvm_analysis_imp_foo #(data type) bar_in

function void write_foo(input ---);
endfunction
function void write_bar(input---);
endfunction

...ap_out.connect(...ap_in)


Complex Module UVC connection(external to intermal)
two ways:
1. Module monitor: all external connections are made to this monitor and monitor is responsible for routing connections to other component in the UVC.
the good:  Single, central location for connecting external TLM interfaces.
the bad: at the expense of additional internal interface connections to other components.

2. Module connections: external TLM interfaces are placed on UVC itself, then routed using hierarchical connections and not separate TLM interface. use of TLM export object
the good: fewer TLM connections
the bad: losing some readability

Port initiators can be connected to port, export, or imp targets.
Export initiators can be connected to export or imp targets.
Imp cannot be a connection initiator. Imp is a target only, and is always the last connections object on a route.

TLM FIFO

Analysis FIFO
uvm_tlm_analysis_fifo is a specialization of uvm_tlm_fifo:
unbounded (size=0)
analysis_export replaces put export, support analysis write method.

uvm_analysis_port ---> analysis_export---analysis_fifo---get_peek_export <---scoreboard_get_port

uvm_tlm_analysis_fifo #(data type) tb_fifo = new("...", this);
uvm_get_port $(data type) sb_in = new("...", this);
function void connect_phase();
    sb_in.connect(tb_fifo.get_peek_export)
endfunction

by the way, analysis fifo's blocking_get_export is just an alias to get_peek_export