SES#1

agenda

1. overview
2. schedule
3. UVM basics

overview:

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
yes.

4. 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.
5. 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.
6. 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.
7. 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.
8. For developing apb_bfm(called as apb_driver in UVM)

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

9. all TB have lot of things in common.
   all TB components also have lot of things in common.
   ex: apb_driver.sv, axi_driver.sv
   o both these components have things in common, also things which they differ.
   o what is common for them? ==> all these are implemented in uvm_driver.sv 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 apb_driver.sv implements APB protocol for tx driving
   o axi_driver.sv 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
   endclass

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

10. Terminology difference
    SV UVM
    Generator Sequencer
    BFM Driver
    Sub environment Agent
    mailbox TLM port, export (Transaction level modeling)
    reference model Scoreboard
    transaction item
11. 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.
12. 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
13. To develop AXI sequencer(AXI generator)
    typedef uvm_sequencer#(axi_tx) axi_sequencer;
14. UVM separates transaction generation and generator in to two different entities
    o transaction generation: sequence
    o generator : sequencer
15. 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
16. UVM is released in multiple revisions
    uvm-1.1c
    uvm-1.1d
    uvm-1.2
17. UVM training pre-requisites
    o Good with SV
    o 3 bit up counter
    o You should be able to develop complete SV based TB
18. UVM is not a tool
    o Guidelines on how to do everything of TB
    o Base classes and macros
19. UVM is easy
    o One TB you develop => 80% of UVM you learn
    o all those concepts are applicable in every UVM based TB.
20. Synopsys developed Vera langauge
    o anyone who develop Tb using Vera, will have to use VCS tool.
21. 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.
22. Memory
    o Same TB using SV & UVM
    o DUT: memory with APB interface
    APB : Advanced peripheral Bus protocol
    atomic write and atomic read
23. we will develop APB UVC component
    UVC: Universal verification component
    APB UVC <===> memory
    to check the memory behavior
24. 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
25. 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
26. memory TB from SV
    o understood at top level what changes are required to port it to UVM based TB
27. in SV, testcase is a stimulus implemented inside generator.
    in UVM, testcase is a component implemented as a separate file.(component)
28. UVM keywords
    uvm_pkg.sv
    import uvm_pkg
    uvm_root
    uvm_test_top
    uvm_component_utils
    factory
    uvm_config_db
29. anything we do in UVM is a class
    SV: print message
    $display(“sampe message”);
    UVM:
    uvm_report_object class is used to print the messages. => it gives lot of flexibility in message printing
30. SV
    event e; //data type
    uvm_event e; //uvm_event is a base class in UVM
31. OOP
    • encapsulation
    • inheritance
    • polymorphism
    • static properties and methods
    • parameterized class
    • abstract class
32. 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: uvm_pkg.sv

33. concept of SV packages

• any time we want to use package, we need to tell, what all things inside package to use.

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

analogy:
– 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.

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

SES#2

revision:

1. What is UVM?
   UVM : base classes + guidelines
   how many base classes are provided as part of UVM?
2. UVM: multiple versions
   1.1b
   1.1c
   1.1d
   1.2
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

Questions:

Agenda:

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

Notes:

1. understanding UVM TB

• top most module
  o uvm_root
  o memory (DUT)
  o interface
  o clock, reset
• uvm_root
  o apb_test uvm_test_top;
  o whatever test we run, it will always be instiantiated as uvm_test_top
• uvm_test(apb_test)
  o apb_env
  o apb_agent (can be one or more)
  o driver, sequencer, monitor, coverage

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

5.
uvm_root
uvm_test
uvm_report_object
– everything brings a level of comfort to the user.

task run();
case(testcase)
“test_wr_10_rd_10” : begin
end
endcase
endtask

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

8.
class uvm-root;
test_wr_10_rd_10 uvm_test_top; //compolsory
endclass

9. 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
10. 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.
11. uvm_cmdline_processor
    SV TB: $value$plusargs to read user arguments
    vsim work.top +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 work.top +UVM_TESTNAME=axi_wr_rd_test
12. root
    analogy:
    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.
13. 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

18. 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.

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

SES#3

questions:

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

revision:

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

Notes:

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

5.
vsim work.top +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.
$value$plusargs
ALL : all ID’s inside the hierarchy

6. 
   UVM_TIMEOUT

vsim work.top +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.

7. 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
8. UVM provdes below arguments for debugging purpose.
   o testcase has failed. why it failed?
   o we need more information
   UVM_PHASE_TRACE
   UVM_OBJECTION_TRACE
   UVM_RESOURCE_DB_TRACE
   UVM_CONFIG_DB_TRACE

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

9. 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
10. Phases
    11.
    function new(string name, uvm_component parent); //function new
    super.new(name, parent);
    endfunction

• any time we create a component, we give two arguemnts
  o name, parent
  o if we create(new) every component with name, parent, UVM will automatically build the TB structure.

9. 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?
10. 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

SES#4

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

3.
Reporting classes
replace the behavior of $display

4. Reporting classes
   • more control on how messaging(~display of messages) should be done
5. 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.
6. If I know that issue is with agent only, then I want lot of messaging from Agent, minimum messaging from other compoennts
7. 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.

SES#5

Questions:

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.

• I am running a PCIe test
  o it is failing
  o I need lot of messaging from PCIe part of TB components, less messaging from other TB components.
  +UVM_VERBOSITY=UVM_LOW ==> This applies for complete testbench.
  +uvm_set_verbosity=uvm_test_top.env.pcie_master_agent.,ALL,UVM_FULL,time,800
  +uvm_set_verbosity=uvm_test_top.env.pcie_slave_agent.,ALL,UVM_FULL,time,800 how to address this?
  +UVM_VERBOSITY=UVM_LOW ==> This applies for complete testbench.
  +uvm_set_verbosity=uvm_test_top.env.pcie_agent.,_ALL,UVM_FULL,time,800 => applies only to components below pcie agent
  +uvm_set_verbosity=uvm_test_top.env.pcie_agent,_ALL,UVM_FULL,time,0 => applies to pcie agent also
  • why time is important?
    o during the reset or power up part of the design, we don’t want any messaging?
    o check how much time it takes to power up or complete reset, lets say 150ns

Notes:

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

3.
env.magent.set_report_verbosity_level(UVM_DEBUG);
//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

4. UVM_SEVERITY?
   o UVM_INFO, WARNING, ERROR, FATAL
   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.
5. 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
6. Home work
   foreach (intA[i]) begin
   $display(“intA[%0d]=%0d”, i, intA[i]);
   End
   Print the same thing using `uvm_info
7. Factory

• what is the difference between magent=new(“magent”, this) and creating the instance using create?
  o we need to create using create method

4. 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

• why do we want to use a factory?
  o why we needed medical factory?
  o it lets us get better control on what formula to use, how much quantity to manufacture, etc
  o medical factory: definiiton is present in server, which can be accessed from anywhere.

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);

SES#6

1. apb_test base class

notes:

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;
endclass

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

2. 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);
3. why should we use factory definition for creating objects?
   analogy:
   – 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
4. uvm-1.1* version
   factory is present in global scope
   uvm_factory factory; //global scope, we can access it from anywhere in TB
5. uvm-1.2 version
   factory is not in global scope
   uvm_factory factory;
   factory = uvm_factory::get();
6. 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.
7. apb_tx =>
   uvm_objects should not be confused wtih class objects.
8. 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());
9. 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
10. in UVM, scenario is implemented as a separate class(sequence)
    • this is separate from sequencer class.
11. 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

13. 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;
endclass

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

13.
UVM_ALL_ON
UVM_PRINT_ON
COPY_ON
COMPARE_ON
PACK_ON
UNPACK_ON
CLONE_ON

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

14. 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.

SES#7

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_default_file_hier(output_file);
   uvm_top.set_report_default_file_hier(output_file_1);
   uvm_top.set_report_default_file_hier(output_file_2);
   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

6.
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

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

9.
set_type_override_by_type/name
set_inst_override_by_type/name

Analogy:
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)

SES#8

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.

8Q.
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

9.
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?

10. 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

SES#9

revision:

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;

Notes:

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)

6. 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.
7. resource_db works independent of TB hierarchy.
   o SCOPE, KEY
8. 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
9. 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
10. TLM is replacing the concept of mailbox
    TLM is impromvent on top of mailbox
11. TLM
12. 1 week : AHB coding, development

SES#10

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.
   o

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

9. 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
10. 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.

12. 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

SES#11

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

SES#12

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

Agenda

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

Notes:

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.
     drv.seq_item_port.connect(sqr.seq_item_export);
     – 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

• observations
  o top module
  o producer
  o stim : stimulus generator
  o tlm_fi : TLM FIFO
  o Conv : Convertor
  o It converts one tx to another tx format
  o consumer
  o tlm_fi : TLM FIFO
  o Drive : Driver
  o WHat this TB part of architecture is doing?
  o stimulus generator is generating txs in one format(axi_tx format).
  o These txs put in to TLM_FIFO
  o To get non-blocking nature.
  o Convertor is getting AXI_TX, converting them to AHB_TX format(some otehr).
  o WHy we are doing conversion?
  o Driver only supports AHB txs, it doens’t support AXI txs. o TB has how many connections?
  o 6 : A, B, C, D, E, F
  o All these connections can be classified in to 3 categories
  o peer-to-peer connection (P2P)
  o componets in same hierarchy level
  o both componets having same parent
  o connection to a component up in the hierarchy (UP)
  o connection to a component down in the hierarchy (DN)
  o A : P2P
  o B : P2P
  o tlm_fi : top.producer.tlm_fifo_i
  o conv : top.producer.conv_i
  o C : UP
  o D : P2P
  o E : DN
  o F : P2P
  o Total
  P2P : 4
  UP : 1
  DN : 1
  o How UVM implements these 3 types of connections?
  P2P : port – export connection
  UP : port to port connection

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

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