1. overview
  2. schedule
  3. UVM basics


  1. UVM essentials and UVM advanced training
    o 9 weeks
    o 4-5 weeks : UVM essentials
    o 4-5 weeks : UVM advanced
  2. UVM
    o UVM is easy
    o UVM is a set of guidelines which makes whole TB development process lot easier

3Q. UVM is important for SV students

  1. PCIe controller veriifcation
    o setting up TB using Verilog
    o 6 months to complete project
    o setting up TB using SV
    o 4.5 months to complete project
    o it comes with lot of constructs(OOP, mailbox, event, smp, etc), which makes TB development lot easier.
    o drawback with SV? we need to spend time to learn SV.
    o setting up TB using UVM
    o 3.5 months to complete project
    o even though we take less time in setting up TB and completing verification, we won’t compromize on verification quality.
  2. Verilog => SV, how time is coming down to 4.5 months?
    o SV has lot of new constrcuts => all those makes it easy to setup TB, testcase development easier.
  3. SV => UVM, how time is coming down to 3.5 months(not exact always)?
    o UVM provides pre-defined base classes, which can be used to setup the TB easily
    o user don’t have to develop TB from scratch.
  4. what are these pre-defined classes?
    o two different designs
    o KBD controller
    o SPI controller
    o All design Testbenches have lot of things in common.
    o UVM implements all those common things as ‘UVM base classes’
    o when User develops TB, user don’t need to code everything from scratch.
    o extend the base class and implmenet the additional functionality.
  5. For developing apb_bfm(called as apb_driver in UVM)

class apb_driver extends uvm_driver;
//implmenet the functionality specific to APB protocol
– uvm_driver is the base class provided as part of UVM package.

  1. all TB have lot of things in common.
    all TB components also have lot of things in common.
    o both these components have things in common, also things which they differ.
    o what is common for them? ==> all these are implemented in file
    o both are connected to sequencer on one side
    o both are connected to DUT using interface on other side
    o both get tx(items) from sequencer, call drive_item task to drive the tx to the DUT
    o both get the response from DUT
    o what is difference in them?
    o implements APB protocol for tx driving
    o implements AXI protocol for tx driving
    o drive_tx code only differs class apb_driver extends uvm_driver#(apb_tx);
    virtual apb_intf vif; //axi_intf
    //all above 4 common things become part of apb_driver
    //user needs to only implement drive_tx specific to APB protocol

what about interfce class w.r.t to UVM ?

  1. Terminology difference
    SV UVM
    Generator Sequencer
    BFM Driver
    Sub environment Agent
    mailbox TLM port, export (Transaction level modeling)
    reference model Scoreboard
    transaction item
  2. People who developed UVM, has made observations about what is common in every TB
    o They have implemented all these common things as ‘UVM base classes’
    o User has to use these base classes and create the required components.
  3. To develop APB sequencer(APB generator)
    typedef uvm_sequencer#(apb_tx) apb_sequencer;
    o UVM is providing us uvm_sequencer, when we parameterize it for apb_tx, it gives us apb_sequencer behavior
  4. To develop AXI sequencer(AXI generator)
    typedef uvm_sequencer#(axi_tx) axi_sequencer;
  5. UVM separates transaction generation and generator in to two different entities
    o transaction generation: sequence
    o generator : sequencer
  6. construct a house
    o pre-fabricated structures
    o where sit-out area shoule be present in house?
    o it also provides me with sit-out area pre fabricated structure.
    o SV: user has to make all decision and also develop from scratch
  7. UVM is released in multiple revisions
  8. UVM training pre-requisites
    o Good with SV
    o 3 bit up counter
    o You should be able to develop complete SV based TB
  9. UVM is not a tool
    o Guidelines on how to do everything of TB
    o Base classes and macros
  10. UVM is easy
    o One TB you develop => 80% of UVM you learn
    o all those concepts are applicable in every UVM based TB.
  11. Synopsys developed Vera langauge
    o anyone who develop Tb using Vera, will have to use VCS tool.
  12. When a TB is developed using UVM, lot of things are uniform
    what is the advantage?
    – new team member joins in to teh project, he/she can immeditely understand the TB.
    o what component is present where?
    o how components are connected?
    o where testcases are developed?
    o where scorebaord is implemented?
    – since every thing is developed as per common methodology, one TB components can be used in anotehr TB.
  13. Memory
    o Same TB using SV & UVM
    o DUT: memory with APB interface
    APB : Advanced peripheral Bus protocol
    atomic write and atomic read
  14. we will develop APB UVC component
    UVC: Universal verification component
    APB UVC <===> memory
    to check the memory behavior
  15. SV based TB architecture
    top module
    top env class(we didn’t use program)
    sub_env class, reference model, checker, scoreboard
    BFM, Generator, Monitor, Coverage
  16. UVM based TB architecture
    top module
    uvm_root(top), call top.run_test() ~similar to program block in SV TBs
    uvm_test_top(testcase user is running)
    top env class(we didn’t use program)
    agent class, scoreboard, checker
    Driver, Sequencer, Monitor, Coverage
  17. memory TB from SV
    o understood at top level what changes are required to port it to UVM based TB
  18. in SV, testcase is a stimulus implemented inside generator.
    in UVM, testcase is a component implemented as a separate file.(component)
  19. UVM keywords
    import uvm_pkg
  20. anything we do in UVM is a class
    SV: print message
    $display(“sampe message”);
    uvm_report_object class is used to print the messages. => it gives lot of flexibility in message printing
  21. SV
    event e; //data type
    uvm_event e; //uvm_event is a base class in UVM
  22. OOP
    • encapsulation
    • inheritance
    • polymorphism
    • static properties and methods
    • parameterized class
    • abstract class
  23. UVM base classes
    • classes implemented as part of UVM library
      src_1.2 is downloaded from accellera

UVM Library:
143 files
Each file having some class or some macro definition.
All these files are included in to one top file:

  1. concept of SV packages

34Q. what is uvm_root?
Is it present in uvm base class hierarchy

– tree root
o this is where the tree starts growing from.
o holds entire structure
– uvm_root
o this is where entire UVM TB structure starts from.

  1. Whetehr to download UVM or use it from tool?
    • preferred to download and use it.
  2. how to setup a simple UVM TB



  1. What is UVM?
    UVM : base classes + guidelines
    how many base classes are provided as part of UVM?
  2. UVM: multiple versions
  3. uvm1.1* and uvm1.2 differs only 2%
  4. UVM has 525 classes defined as part of its library
    o we use only around 40 base classes in TB development
    o 8 categories
    o classes used for TB component development
    o uvm_driver
    o uvm_monitor
    o uvm_sequencer
    o uvm_subscriber
    o uvm_scoreboard
    o uvm_agent
    o uvm_env
    o uvm_test
    o uvm_component
    o classes used for TB component connections
    o uvm_seq_item_port
    o uvm_seq_item_export
    o uvm_blocking_port
    o uvm_analysis_port
    o classes used for TB scenario creation
    o uvm_object
    o uvm_transaction
    o uvm_sequence_item
    o uvm_sequence
    o classes used for TB database(utility) creation
    o uvm_factory
    o uvm_resourse_db
    o uvm_config_db
    o uvm_pool
    o uvm_object_string_pool
    o classes used for message reporting purpose
    o uvm_report_object
    o uvm_report_server
    o uvm_report_handler
    o uvm_report_catcher
    o classes used for synchronization purpose
    o uvm_event
    o uvm_barrier
    o classes used for reading user arguments and starting the TB, deciding when to end test
    o uvm_cmdline_processor
    o uvm_objection
    o uvm_root
    o classes used for register model development
    o uvm_reg
    o uvm_reg_field
    o uvm_mem
    o uvm_reg_block
    o uvm_reg_file
  5. next 4-5 weeks, our focus will be on how to use above 40+ base classes effectively.
    UVM making TB developemtn lot easier.
    – It provides us with base implmentation as part of base class(ex: uvm_driver, uvm_monitor, etc)
  6. how verification completion timelines reduce when we go from Verilog->SV->UVM
  7. we took memory SV TB, understood how to port it to UVM TB
    o uvm_config_db, uvm_factory, seq_item_port, etc



  1. understanding UVM TB
  2. uvm base classes, uvm_reporting
  3. what is uvm_root?
  4. UVM TB template coding


  1. understanding UVM TB
  1. as we increase number of design interfaces, we need to add more agents.
    o If I have a design with 7 interfaces
    o 3 AXI master interfaces
    o 3 AXI Master agents
    o 3 AXI slave interfaces
    o 3 AXI Slave agents
    o 1 APB master interfaces
    o 1 APB master agent
    o how many agents required totally?
    o 7
    o How to draw TB architecture for this design with 7 interfaces?
    o what is meant by master interface?
    o DUT will act like a slave
    o External component acts like a master
  2. If a design has 5 interfaces, how many agents will be requried? 5
    o only decision to make is?
    o master agent or slave agent?
  3. term ‘env, sub_env’ is misleading => it doesn’t give me an idea of how many actual compoentns are there below them.
    agent is very simple and straighforward
    o one master agent means => one driver + one sequencer + one monitor + one coverage
    o one slave agent means => one driver + one monitor

– everything brings a level of comfort to the user.

task run();
“test_wr_10_rd_10” : begin

  1. imp => implementation
  2. SV TB
    o user calls $finish to decide when to end test
    UVM TB
    o concept of test case ednding is implemented using objections.

class uvm-root;
test_wr_10_rd_10 uvm_test_top; //compolsory

  1. UVM Root
    o starting point of UVM TB hierarchy
    o it takes of following things
    o It automatically calls uvm_cmdline_processor to read the user arguments
    o UVM root automatically decides which test case to run
    o It create a uvm_phase phase
    o this phase is passed to all UVM TB components, these components keep track of the TB execution phase using the phase object
    o uvm_root automatically calls all the components various phases in specific predefined order
    o uvm_root uses concept of objections to decide when to end the testcase
    o root is similar to root of tree.
    o it holds the complete TB structure
    o uvm_root top; //user don’t need to write this line, it happens automatically
    o it happens automatically
    o this all starts when user calls ‘run_test’ in top most module
    o it is a singelton class
    o whole UVM TB will only have one instance of uvm_root
    o ex: uvm_root top1, top2; //now uvm_root is not singelton class
  2. run_test do?
    o defined in global scope
    o it creates uvm_root top
    o top memory is allocated
    o top.run_test(test_name) is called
    o top.run_test
    o does every thing o uvm_root automatically calls all the components various phases in specific predefined order
    o in UVM, every TB component functionality is divided in to multi phases
    o build_phase
    o connect_phase
    o end_of_elaboration_phase
    o start_of_simulation_phase
    o run_phase ===> only task
    o extract_phase
    o check_phase
    o report_phase
    o does AXI Driver has all above phases? yes
    o does axi_10_tx_test has all above phases? yes
    o in SV based TBs, user needs to call the sub component methods manually
    o in UVM based TBs, these methods gets called automatically => VERY IMP
    o UVM root ensures that all the components build_phase gets called automatically in top-down order
    o once build_phase is completed, uvm_root ensures that connect_phase of all the compoents gets called
    o once connect_phase is completed, uvm_root ensures that end_of_elaboration_phase of all the compoents gets called
    o so on till we reach report_phase => at that stage automatically $finish gets called.
  3. uvm_cmdline_processor
    SV TB: $value$plusargs to read user arguments
    vsim +testname=axi_wr_rd_test
    UVM TB: uvm_cmdline_processor automatically does that work for the user.
    o UVM has some standard arguments, which uvm_cmdline_processor will automatically parse it.
    vsim +UVM_TESTNAME=axi_wr_rd_test
  4. root
    tree root we don’t see, but it is very important
    o we don’t have forcedfully feed the tree.
    UVM root we don’t see directly while working with UVM TB, but it is very important.
    o it brings in lot of automation in to the whole TB flow.
  5. UVM separates testcase and scenario in to different entities
    o in SV, both are implemented in to generator::run task
    o in UVM,
    scenario is implemented as a sequence
    test in turn calls this sequence.
    o sequence and test are implemneted separately.
    o this separate implementation helps with reusability of sequences.

14Q. in SV we use program block to have simulation in reactive region to avoide race condition, is uvm root also work in reactive region?
o UVM ROOT doens’t work in reactive region.
o top.run_test => falls in active region since module initial, it is called in.
o reactive region concept is only at starting movement(0th ns time) point of TB
o hence it doesn’t do any value addition even by using program block.
o currently, ‘program’ block is redundant, many companies don’t use.

15Q. accelera portal we have stable version “UVM_1800.2-2017-1.0” ,we need to use or uvm-1.2 ?
o uvm-1.2

16Q. can you give a real life example of what the slave agent will do in this kind of design?
o USB controller

17Q. where can we download the base classes codes of UVM ?? if possible can u say/ share the link where it is available.
accelera UVM in google

  1. Objection
    analogy: court case hearing
    o court(Complete TB), Judge(uvm_root), lawyer(UVM TB components: sequencer, etc)
    o some case hearing(some testcase being run) is happening
    o few lawyers(some of TB components) raise their objections(component is telling that, my functionality is still running)
    o unless all those objections are dropped, case can’t be closed(testcase simulation can’t be ended) o few lawyers wanted some thing to tell => Judge decided to end the case => Abrupt finish o SV TB: $finish many times results in abrupt ending of test. o top module don't know the condition of other components. o UVM TB o every component is telling, I have a objection, so don't finish simulation now. o only when, all objections are dropped, simulation will finish.

19Q. do we have any default drain time value?
– default drain time 0ns

20Q. what do you mean by “objection is internally calling $finish”?
o $finish is called in UVM TB also
o objection mechasim takes care of it.

21Q. why result changes when we run in 1.2 as `uvm_info is 5 in 1.1d and 6 in 1.2?
o you change it, you run it, find the additional message, get back to me.

  1. we need 5 clock cycle drain time
    1 cycle to drive, 3 cycle of DUT to process, 1 cycle to get response
    how much should be drain time?
    5*20ns = 100ns
    phase.phase_done.set_drain_time(this, 100);



  1. how starting_phase gets to know which phase is running?


  1. Objections
  2. uvm_root
  3. UVM based TB looks like
    o how it differs from SV TB


  1. Given any SV TB
    o we can convert the same to UVM TB => time depends on complexity => 30 mins to 1 hour
    o whole TB becomes well organized.
    o TB becomes easy to work with
    o ease of developing the testcases
    o ease of debugging testcase failures
    o ease of printing the messages
    o another 20-30 points will be there.
  2. UVM command line processor
  3. uvm_info, uvm_driver, uvm_test
  4. Verbosity
    o what level of printing we want to do in testbench.
    o if we want to do lot of messaging(~$display) => UVM_FULL versboe
    o if we want to do less messaging(~$display) => UVM_LOW versboe

vsim +UVM_VERBOSITY=UVM_LOW +uvm_set_verbosity=uvm_test_top.env0.agent1.*,ALL,UVM_FULL,time,800 +xyz=10
xyz will be read by uvm_cmdline_processor?? No
xyz is not part of the uvm_cmdline_processor arugment list.
ALL : all ID’s inside the hierarchy


vsim +UVM_VERBOSITY=UVM_LOW +uvm_set_verbosity=uvm_test_top.env0.agent1.*,ALL,UVM_FULL,time,800 +UVM_TIMEOUT=5000
o whatever happens, simulation will compolsorily finish at 5000.

  1. UVM_MAX_QUIT_COUNT=10 or 20
    o UVM can report messages as error or warning or info
    o by default, when error happens, error_count gets incremented.
    o whenever error_count=10, simulation finishes.
    o why is it important in a complex project?
    o if we run a test, lets say, we get 500 errors
    o these 500 errors all repeating => 10 unique errors
    o to get 10 errors => 1ms simulation time
    o to get 500 errors => 50ms simulation time => run time increases by 50 times
  2. UVM provdes below arguments for debugging purpose.
    o testcase has failed. why it failed?
    o we need more information

TRACE is common in all:
– trace the error => debugging something.

  1. for a verification engineer, is uvm_cmdline_processor good or bad?
    o good
    o user don’t have write $value$plusargs to read the arguemnts
    o it gives more control on messaging, timeout, debugging, etc
  2. Phases
    function new(string name, uvm_component parent); //function new, parent);
  1. Analogy
    • combined family of 50 members
      o name of the person
      o who is the parents(father) of the person
      o with above details, can we come up with complete family tree?
  2. when I am developing any TB component, only question we need to answer is?
    o which phases are releavent to which components
    o test : connect_phase is not relevant
    o agent: end_of_elaboration_phase, run_phase is not relevant => they will be trrated as empty methods


  1. UVM Testbench/component phases
    o common phases
    o build_phase
    o connect_phase
    o report_phase
    o scheduled phases
    o run_phase of any component can be further divided in to 4 sub phases
    o reset_phase
    o phase is reset is applied to the design, what is the current TB component is supposed to during this time.
    o configure_phase
    o make sure that design reset has completed, then go for configure_phase
    o register programming => anything do with design configuration(register programming)
    o main_phase
    o we generate the traffic(transactions) once the design is configured
    o shutdown_phase
    o anything we want to do as final closing thing
  2. any component in UVM TB
    o driver, monitor, sequencer =>
    o common phases compolsory exists

Reporting classes
replace the behavior of $display

  1. Reporting classes
    • more control on how messaging(~display of messages) should be done
  2. complex projects
    o number of lines in a log file will be around 1000 lines to 1lakh lines
    o very difficult to debug 100000 lines
    o if same can be reduced to 2000 lines, debug becomes easier.
  3. If I know that issue is with agent only, then I want lot of messaging from Agent, minimum messaging from other compoennts
  4. vsim top -sv_lib C:/questasim64_10.6b/uvm-1.2/win64/uvm_dpi +UVM_VERBOSITY=UVM_NONE
    Reference Verbosity takes effect for complete testbench.
    UVM provides me flexibility where I can keep complete testbench with some refernce verbosity, few of the components with a different verbosity.



  1. What exactly does +uvm_set_verbosity does and what is the difference between env.magent* and env.magent.* in the path field of the above command line argument?

+UVM_VERBOSITY=UVM_LOW ==> This applies for complete testbench.
+uvm_set_verbosity=uvm_test_top.env0.agent1.*,ALL,UVM_FULL,time,800 ==> This applies only for specific hierarchy in the testbench.


  1. uvm_set_verbosity can be done from TB also, by calling functions.
  2. uvm_warning,uvm_error, `uvm_fatal => by default print

//aplies only to magent
env.magent.set_report_id_verbosity(“MAGENT_1”, UVM_NONE);
//aplies only to magent, with MAGENT_1 ID messages only
//all other messages will have reference_verbosity=UVM_DEBUG
env.magent.set_report_severity_id_verbosity (UVM_INFO, “MAGENT_1”, UVM_DEBUG);

`uvm_warning => by default print
    o is there real case, where we want to turn off warning and errors? No
    o action(what happens when these messages happen?) => default behavior provided by UVM
    o uvm_info happens => only print happens ouvm_warning happens => only print happens
    o uvm_error happens => print happens + error_count gets incremented by +1 o whenever this count matches UVM_MAX_QUIT_COUNT value, simulation $finish called ouvm_fatal happens => simulation $finish called immediately
    o we can change this default action level
    uvm_set_action => 99% of time you won’t do it.
  2. uvm_info and uvm_report_info o how these 2 are related? uvm_info is calling uvm_report_info
    99% of times, we prefer using `uvm_info only
  3. Home work
    foreach (intA[i]) begin
    $display(“intA[%0d]=%0d”, i, intA[i]);
    Print the same thing using `uvm_info
  4. Factory
  1. Factory analogy
    • chemical factroy
    • car factory
      o car gets manufactured
    • medical factory
      o medicines gets manufactured
    • UVM factory
      o UVM components and objects gets manufactured

UVM Factory is a global database of all component and object definitions, which can be accessed from any part of the testbench and these definitions can be changed/updated as per the current test case requirements.

Medical Factory is a global database of all tablets and syrup definitions, which can be accessed from any part of the world and these(tablets and syrup) definitions can be changed/updated as per the current manufacturing requirements.
o we need to add formula of tabler and syrup to the factroy.server
uvm_component_utils(apb_driver) ==> we are adding the definiitin of apb_driver to the UVM factory uvm_object_utils(apb_tx) ==> we are adding the definiitin of apb_tx to the UVM factory

Medical faactory
o paper
o drv = new(“drv”, this);
o factory server => since factory has latest definition => we prefer using create
o drv = apb_drv::type_id::create(“drv”, this);


  1. apb_test base class


  1. factory
    • medical factory
    • whatever components and objects are in the TB environemtn, all those definitions are registered with factory.

class apb_tx extends uvm_sequence_item;
`uvm_object_utils(apb_tx) //we are registering apb_tx definition to the factory
rand bit [31:0] addr;
rand bit [31:0] data;
rand bit [31:0] wr_rd;

apb_tx tx;
tx = new(); //SV file definition used
tx = apb_tx::type_id::create(“tx”);
– apb_tx::type_id is the factory definition of apb_tx

  1. when tx is created, we only pass one argument
    when component instance is created, we pass two arguments
    apb_drv drv = new(“drv”, this);
    apb_drv drv = apb_drv::type_id::create(“drv”, this);
  2. why should we use factory definition for creating objects?
    – Crocin syrup formula
    – definition is on paper
    o you need to be physical present wherever paper is tehre
    – definition is registered to the factory server
    o this is easy to update the formula
    o you can access factory server from anywhere and do the updates.
    o we can selectively choose one definition for one geograhical region and another definition for other region.
    UVM Factory:
    – component/object definition is registered to the factory
    o these definitions can be easily updated as per user requirements
    o we can do component/object definitions updates from anywhere in the TB
    o we can have different definitions for same component in different parts of TB.
    o when we register these definitions with factory, we get methods like print, copy, compare, pack and unpack automatically implemented.
    – how do we do updates to the factory?
    o uvm_config_db
    o uvm_config_db is linked to the factory, we can do factory definition updates.
    o set_type_override and set_inst_override
    o we can change the overall definition itself by using these methods
  3. uvm-1.1* version
    factory is present in global scope
    uvm_factory factory; //global scope, we can access it from anywhere in TB
  4. uvm-1.2 version
    factory is not in global scope
    uvm_factory factory;
    factory = uvm_factory::get();
  5. any TB component => uvm_component
    driver, mon, sequencer, scoreboard, test, env, agent => components
    o components are created at time=0, they exist till end of the simulation.
    any tx, pkt, sequence, scenario => uvm_object
    o objects are created at the run time, they are consumed, and their memory gets deleted.
  6. apb_tx =>
    uvm_objects should not be confused wtih class objects.
  7. Every uvm_component/uvm_object in UVM has two ways to identify them.
    • type
      o type = apb_tx
    • name
      o name = “apb_tx”
    • create an instance of apb_tx
      o create_object_by_type(apb_tx::get_type());
  8. apb_driver, apb_monitor, etc
    o all of them two ways in which they can be identified
    o type => apb_driver::get_type()
    o type_name => “apb_driver”
    o analogy:
    o crocin => can be idenfied by its name, by its formula
    o get_object_type analogy
    o one bottle without any label
    o what is the medicine
    o bottle.get_object_type() => Crocin
    o tx_1
    o tx_1.get_object_type() => apb_tx is return type
  9. in UVM, scenario is implemented as a separate class(sequence)
    • this is separate from sequencer class.
  10. who is initiator between driver and sequencer ?
    o driver is the initiator(master)
    o sequencer is the responder(slave)

12Q. why we need to pass tx item as a argument for class

  1. Once we reach this stage of TB development and monitor, coverage
    o from this point onwards, it is same as SV coding

class axi_tx_req;
rand bit [31:0] addr;
rand bit [31:0] data;

class axi_tx_rsp;
rand bit [1:0] resp;


earlier print method is empty => update print method for print these additional fields

  1. I want to create a new testcase
    o write to one location: 1000
    o read from the same location: 1000
    • to create any testcase, we need to create a sequence
      o then map testcase with the sequence

15Q. A driver can be connected to multiple sequencer?
o not possible

16Q. is the data that we are getting is same as we are writing and reading from the same location
o right now no DUT.


  1. uvm_info("apb_base_test","build_phase : for apb_base_test!!!!",UVM_MEDIUM); uvm_warning(“apb_base_test”,”build_phase : for apb_base_test!!!!”);
    uvm_error("apb_base_test","build_phase : for apb_base_test!!!!"); //uvm_error(“apb_base_test”,”build_phase : for apb_base_test!!!!”);
    //env = new(“env”,this); // name : env ,this : parent = apb_env //old method
    env = apb_env::type_id::create(“env”,this);
    uvm_top.set_report_severity_action_hier(UVM_INFO, UVM_LOG);
  2. all output goes to transcript file
    many times transcript can be very big : 1 lakh lines or 10000 lines
  3. setup TB enviornemnt
    o how to develop testcases?
    o develop the sequence, map this sequence to our testcase.
  4. UVM
    o we purposefully keep testcase and sequences in different parts.
    o reason:
    o sequences can be reused to create bigger sequences.
    o test can’t be reused to create bigger tests.
  5. Summary
    • we have integrated memory in to testbench.
      o did the connections using interface(same as in SV)
    • o drive_tx method (same as in SV)
    • we implemented, 5 wr-rd tx testcase

If in a Dut we have inout ports, how to write a sequence for it?
o noway related to UVM
o inout ports dirivng need

  1. 10,14,18,1c,20
  2. virtual sequencer
    uvm_do_on uvm_do_on_with


medical factory
– crocin syrup (~apb_tx)
– new_crocin syrup (~apb_err_tx)
for whole of India(~complete TB), crocin(~apb_tx) definiton should be replaced with new_crocin(~apb_err_tx) syrup. => done in medical factory server(uvm_factory)
o type override(when override applies to the complete TB)
for whole of India, crocin definiton should be same, only for KA, new_crocin definiton should be used.
o inst override(India.KA, new_crocin)


  1. override
    • concept of changing the definition inside the factory.
      why to do override?
    • apb_tx overridden with apb_err_tx
      • I want to create some error testcases.
    • apb_driver overridden with apb_err_drv
      • I want to get error testcase behavior
  2. override
    o to create new testcase, we don’t have to redevelop the complete code.
    o just need to override.
  3. without using override, we can create sequence using apb_err_tx, then generate sequence
  4. how many types of overrides?
    o type override
    o override happens in complete factory(applicable to whole TB)
    o instance override
    o override happens only in specific hierarchy
  5. analogy
    o crocin formula can be repalced with new_crocin
    o crocin formula can;t be repalced with something else
  6. 99% of times(~100%) override is always done from the testcase::build_phase
    • all the phases happen after build_phase, they will take effect of the override.
  7. we can reuse same sequence for different testcases.

when we override one tx class with other and if we have extra properties in the new class then how will it be used in the or should we change the tb code?
o yes, TB code also should be changed

What is factory?
How factory makes TB development easier?
What are the commonly used methods in factory?
Is it possible to create a component or object directly from factory?
What is override?
What is type and inst override?
How override concept is useful in testcase development?
What factory.print does?
Explain override concept using an example?
How factory usage differs between uvm-1.1 and 1.2?

  1. config_db
    • similar to apb_common class, where we keep all commonly shared variables, so that they can be accessed anywehre in the TB.
      o config_db is better way of doing apb_common concept



  1. config_db
    o better way of implementing apb_common::static_variables
    o sharing the variables in complete TB
    o we can restrict who has the access to the variables
    o concept of auto retrival works
    o for int variables, without even calling get, retrival happens.
    o config_db updates can be specific to the testcase
    o they won’t apply to other testcases.
    o testcase::build_phase
  2. context, inst_name
    context: handle(starting component handle)
    inst_name : string
    o * : to refer to multiple hierarchies
    o env.magent.*
    o to refer all agents and components below
    o env.agent
    o to refer components below all agents
    o env.agent.
    without this concept:
    env.magent.drv.count = 10;
    env.magent.mon.count = 10;
    env.magent.sqr.count = 10;


  1. uvm_config_db#(data_type)::set, get
    o TB can be divided in to 3 aspects
    o top most module
    o any class based component(any TB component)
    o any object(sequences)
    o 3*2 = 6 combinations
  2. sequences
    o they don’t have hierarchy
    o sequences doens’t support auto-retreival, since sequences don’t have build_phase
  3. uvm_config_db can be used to impact TB structure from test::build_phase
  4. in build_phase or connect_phase, if uvm_error is reported, simulaiton immediately exits with fatal error.

5Q. can we use uvm_factory instead of uvm_root ,since it has the definitions of all the components and objects?
o uvm_factory is not part of hierarchy
o uvm_root refers to the hierarchy(starting point of TB)

  1. resource_db
    o concept is same as config_db
    o we do same thing as what we do with config_db, but in a different way.
  2. resource_db works independent of TB hierarchy.
    o SCOPE, KEY
  3. TLM
    • transaction level modeling
    • communication between components, happens in terms of transactions.
      transaction = an object that has request+response infomration.
    • sqr -> drv
      o uvm_sequnece_item => transaction
      o communication between sqr and drv is called as TLM
  4. TLM
    o port, export, implementation_port(imp_port)
    o Analogy
    o India is getting crude oil from Iran
    o India can be deciding one, Iran can be obeying India terms
    o India : master
    o port
    o Iran : slave
    o Imp_port(~export)
    o class world_agent extends uvm_agent;
    India India_1;
    Iran Iran_1; function void connect_phase(uvm_phase phase); India_1.port.connect(Iran_1.export); endfunction o crude oil => Barrels (transaction) o India being master, it raises request, I need this many barrers. endclass
  5. TLM is replacing the concept of mailbox
    TLM is impromvent on top of mailbox
  6. TLM
  7. 1 week : AHB coding, development


  1. square : port
    circle : export or imp_port
    rambus : analysis port
  2. wherever port is there, it is the master
    wherever export/imp_port/analysis_imp is there, it is the slave
    wherever analysis port is there, it is the master(it is giving txs)
  3. None of the TLM base classes are registered to the factory
    o to create their instances, we must always use new only
  4. whenever we create imp port => pass 2 arguemnts to the class
  5. TLM connections
    o port outside
    o imp/export inside the brackets
  6. in FIFO model, both producer and consumer acts like masters
    what does it mean?
    o they decide when to get the txs.

7Q. what is the usecase of tlm_fifo ?where do we use?
o Push and pull model => blocking in nature
o if we need producer and consumer to work independetly, then use FIFO model.

8Q. Is there any difference between export and implementation port or are they same?
o they are different in some aspects

  1. Essence of TLM
    o one component calls the method, other component implements that method
    o as part of the method argument, we pass the argument => that is how tx is going from one component to other
  2. sequencer is mapped to one sequence
    o when sequencer gets the get_next_item call, it gets one item from the mapped sequence.
    o that item is given to the driver.
    o driver will drive it(drive_tx)
    o once this method is completed
    o driver needs to tell sequencer that I am done with the item.
    o seq_item_port.item_done();

11Q. how sequencer comes to know , rsp belongs to which tx ?
o every sequence item has ‘sequence_item_id’ using that tx-rsp can be mapped.

  1. test library
    o always develop test library as 2 parts
    o base test
    o all the common things of all the test will be kept in base test.
    – factory handle
    – env
    – env created
    – print topology
    – factory print
    o functional tests


  1. driver giving rsp, sequencer getting the response
    o matching the transaction_id
  2. TLM complex example
  3. FSM verificaiton
    o how bidrectional communication helps
  4. active agent
    passive agent
    master agent
    slave agent


  1. Analysis port: broadcast model
    o analogy:
    – Dish Setup box
    – Airtel Digital TV ==> producer
    o all of us gets some set of information
    o each of us view different channels. (all of us: subscriber)
    o write method(through which we get complete signals)
    – we can send channels to Digital TV
    o Analysis model is only one directional.
    o we can’t send tx from subscriber to producer.
    o whereas in Sqr-driver communiaiton, bidrectional is possible


  1. TLM TB
  2. How Sqr-Drv bidrectional communiaiton works


  1. Push, pull model we learnt, is only for basic concept understanidng purpose.
    o we won’t use at that level.
    • for Sqr-drv communiaiton, already UVM itself provides the port names.
      – UVM has already defined seq_item_port and seq_item_export
      – we don’t even need to do new for above ports(UVM already does it)
  2. TLM TB

3Q. in export, we don’t need to pass the second argument in paramter?
o not required

can we just blindly write raise and drop objections in all the run phase we use?

Course Registration