Sei sulla pagina 1di 6

UVM Checklist:

1. UVM Based TB Architecture


o Top_most_module -> Test -> env -> sub_env -> agent -> driver, sequencer, monitor
o Testbench is created for each testcase
o Tests are coded in test library file(similar to package with all tests defines in single file)
o Test library file is included in top most module
o Program block is not used in UVM TB
2. Running Test in UVM
o vsim +novopt work,top +UVM_TESTNAME=name_of_test
o run_test() must be called from initial block in top most module
o run_test(testname) can be passed to run a test. But not preferred since it ties testbench to single test.
o If the run_test()/UVM_TESTNAME testname is not registered in the UVM factory, then simulation will result in
fatal error
o If run_test() not called in top most module, uvm phase does not get called. We can still call global UVM methods
3. Phases in testbench run
o build_phase
o Config_phase
o end_of_elaboration_phase
o Start_of_simulation_phase
o run_phase
o extract
o check
o report
4. Reporting messages
o Managing reporting using +UVM_VERBOSITY & +UVM_SEVERITY
o UVM_VERBOSITY: Simulation command option to change the verbosity for all UVM components.
o +uvm_set_verbosity option has a specific format that allows control over the phases where the verbosity
change applies, and in the case of time consuming phases exactly what time it applies.
sim_cmd +uvm_set_verbosity=component_name,id,verbosity,phase_name,optional_time
sim_cmd +uvm_set_action=component_name,id,severity,action
sim_cmd +uvm_set_severity=component_name,id,current_severity,new_severity
o uvm_report_info/warning/error/fatal
o virtual function void uvm_report_info(string id,string message,int verbosity = UVM_MEDIUM,string filename = "",int
line=0)
o sequence items and sequences use the sequencer which they are associated with for reporting messages. If no
sequencer set, then global reported will be used.
o `uvm_info/warning/error/debug/fatal
o `uvm_info(ID,MSG,VERBOSITY) : Calls uvm_report_info if VERBOSITY is lower than the configured verbosity of the
associated reporter. ID : message tag. The line and file name sent to the uvm_report_info call
o `uvm_warning/error/fatal(ID,MSG) : Calls uvm_report_warning/error/fatal with UVM_NONE verbosity, hence
cant be disabled by using the reported verbosity settings, but can be turned off by setting the action for the message
o UVM_VERBOSITY: UVM_NONE/LOW/MEDIUM/HIGH/FULL
o UVM_NONE: Report is always printed. Verbosity level setting cant disable it
o UVM_LOW: Report is issued if configured verbosity is set to UVM_LOW or
above(UVM_MEDIUM/HIGH/FULL)
o UVM_SEVERITY: UVM_INFO/WARNING/ERROR/FATAL
o UVM_FATAL: Simulation exists on this severity level using $finish.
5. TB component coding
i. Driver
o Extends from uvm_driver#(REQ, RSP)
o Instantiate virtual interface
o Declare config variables, to give provision to update component behavior from test
o Register to factory using `uvm_component_utils
o Get Virtual interface handle using : uvm_config_db#(virtual ubus_if)::get(this, "", "vif", vif)
o Implement driver functionality in run_phase
o rsp to be given back to sequence should be fill with id information using rsp.set_id_info(req)
ii. Sequencer
o Extends from uvm_sequencer#(REQ, RSP)
o register to factory using `uvm_component_utils
o typedef of uvm_sequencer#(REQ, RSP) can also be used to define sequencer
o `uvm_sequencer_utils used to provide automation macros for sequencers.
o `uvm_update_sequence_lib_and_item(simple_item); function new to indicate generated data item type
iii. Monitor
o Extends from uvm_monitor (Note : no parameter)
o Instantiate analysis port using uvm_analysis_port #(Tx_name)
o Delcare any configuration variables to effect the monitor behavior, register these to factory
o Give collected transaction to connected analysis implementation ports using ap.write(tx)
iv. Functional Coverage
o Extends from uvm_subscriber (Note : no parameter)
o Instantiate analysis implmenetation port using uvm_analysis_imp #(Tx_name, Cov_Class_name)
o Create covergroup definitions, new covergorup in function new()
o Trigger event for coverage or smaple covergroup in write task
o write task is called whenever monitor calls ap.write(tx)
v. Scoreboard
o Extends from uvm_scoreboard
o Declare uvm_analysis_imp_decl(<INTF_SPECIFIC_NAME>), this create write_<INTF_SPECIFIC_NAME> method
o Above declared analysis imp is connected to corresponding monitor analysis port
o When monitor calls ap.write(tx), above write_<INST_SPEC_NAME> method gets called
vi. Comparator
o UVM inherently provides 2 comparators: uvm_in_order_comparator, uvm_algorithmic_comparator
vii. Register Layer
o Created using uvm_reg_block, uvm_reg_field, uvm_reg_map, uvm_reg
6. Configuration object
o Common container class used to hold all the environment related configuration variables, interface handles
7. Ending testcase run
o global_stop_request() is used to end the test. It is called in the run phase of test with after required test run
time. +UVM_USE_OVM_RUN_SEMANTIC should be for global_stop_request() to work in UVM.
o raise_objection and drop_objection is the preferred way of terminating test. All objections dropped implicitly
calls global_stop_request.
o Dropping all objections issue stop_request, which will stop all the threads in the testbench
o Any raise objection will disable global_stop_request effect.
o Not using objections or global_stop_request make test to run till simulation time out at UVM_ERROR @ 9200sec
o Using $finish instead of global_stop_request will make test to exit without running extract, check, report phases
8. Passing Interface, Configuration object in complete TB hierarchy
o Setting Virtual Interface handle
o uvm_config_db#(virtual ubus_if)::set(null,"ubus_example_tb0.*", "vif",vif);
o Getting Virtual Interface handle from Testbench components
o if(!uvm_config_db#(virtual ubus_if)::get(this,, "vif",vif)) `uvm_fatal("NOVIF",{"virtual interface must be set for:
", get_full_name(),".vif"});
9. Registering component to Factory
i. Creates type_id with get, get_type, create methods
Type_id: typedef uvm_object_registry #(Component_name) type_id;
ii. Convinience layer for config_db access
10. Registering objects to Factory
11. Modifying the testbench topology for testcase requirements
i. set_inst_override
ii. set_type_override
iii. uvm_config_db
iv. uvm_resource_db
v. set_inst_override_by_name
vi. set_inst_override_by_type
vii. set_type_override_by_type
viii. set_type_override_by_name
ix. set_config_int/string/object (get_config_int/string/object)
12. Different types of ports in TLM1.0
i. port/export/fifo
ii. Different models in TLM1.0 Communication
o Push
o Pull
o FIFO
o Analysis
iii. Possible port connections
o port-export
o export-export
o export-port
13. Different types of sockets in TLM2.0
i. sockets
ii. blocking transport examples
iii. non blocking transport examples
iv. Keeping track of time and phase of execution of transaction
14. Printing testbench topology
i. printing in different format (table, tree, line)
15. Scorebaord implementation
i. Scoreboard with multiple monitor connections
o uvm_analysis_port_decl macro to create multiple write_* methods
o uvm_analysis_export & uvm_tlm_analysis_fifo based implementation
16. Create common pool of resources
i. uvm_pool
ii. uvm_resources
17. Coding PKT data item for serial communication protocols
o Using concept of knobs to generate multiple interesting scenarios specific to each test
18. Coding Transaction data item for on-chip communication protocols
o Using concept of knobs to generate multiple interesting scenarios specific to each test
19. Standard connection types used in all UVM based TB environments
o BFM to sequencer
o driver.seq_item_port.connect(sequencer.seq_item_export);
o driver.rsp_port.connect(sequencer.rsp_export);
o rsp_port needs connecting only if driver will use it to write responses the the analysis export in the sequencer.
o Methods available for driver to communicate back to sequencer(item_done, put_response)
o seq_item_port.item_done() //Indicate transaction is done
o seq_item_port.put_response(rsp) //Provide response, sequence must use get_response(rsp) to unblock put
o rsp_port.write(rsp)
20. Sequence coding
Coding concepts:
o function new with name of sequence as argument,
o `uvm_sequence_utils(sequence_name, sequencer_name) to enable UVM automation macros for sequence
o above macro provides a p_sequencer variable that is of the type specified by second argument of the macro. This allows
access to derived type specific sequencer properties.
o Layered sequence coding
o Calling items
o calling sub sequences
o pre_body, post_body significance
o set_config_int("*.cpu_seqr", "count", 10); To generate and send 10 sequences
21. Virtual sequence coding
o Need for virtual sequence
o different modes of running virtual sequence
o business as usual
o disable other sequences
o grab & ungrab
22. Virtual sequencer
o Top level sequencer which has handles to other sequencers, used to execute that corresponding sequences.
o Does not have items of its own
o Assigning sequencer handles in virtual sequencer
o v_sequencer.cpu_seqr = cpu0.master[0].sequencer;
uvm_config_db#(uvm_sequencer)::set(this,v_sequencer,eth_seqr,eth0.tx_rx_agent.sequencer);
23. Executing sequences
- `uvm_do
- `uvm_do_with
- `uvm_do_on
- `uvm_do_on_with
- `uvm_do_on_pri
- `uvm_do_on_send
- start
24. Executing items
o start_item(req)
o finish_item(req)
25. Linking testcase to a sequence using default sequence
o sequence.start(sequencer)
o setting default_sequence using uvm_config_db for each phase of execution
26. uvm_objection to track testbench execution progress
o Objection used in run phases of different components and body of seqeunces
o Number of objections can be tracked
o When a objection is dropped, dropped method is called
o setting drain time using set_drain_time, makes test run for additional drain time after objection drop.
27. Creating sequence library
o declaring sequence library
o adding sequence to sequence library
o running tests with sequence library
o Inherent sequence running modes, count
o Default sequences in library
o sequences execute an uvm_random_sequence object by default, sequences will be generated in a loop by default
o uvm_exhaustive_sequence: Randomly selects and executes once each sequence from the sequencers sequence library
o if sequencer Count=0, the sequencer will not automatically start a sequence
o uvm_simple_sequence: Generate one item
28. Updating component definition
o uvm_config_db
o uvm_resource_db
o callbacks
o use inheritance and update virtual method definition
29. Coding reusable verification environment using UVM
o Active UVC & Passive UVC
o Design UVC represents Reference model equivalant
30. Register Layer in testbench
o Need for register layer?
o where does register layer fit in to testbench hierarchy
o base classes in register layer implmentation
o standard methods to access register layer block/regs/fields
o adaptor
o creating register access tests using register layer
o functional coverage implementation in register layer
o predefined sequences in UVM register layer
o implementing frontdoor & backdoor accesses
30. Factory Classes

31. Barrier, Pool, event


o The uvm_barrier class provides a multiprocess synchronization mechanism. It enables a set of processes to block until
the desired number of processes get to the synchronization point, at which time all of the processes are released.
o Implements a class-based dynamic associative array. Allows sparse arrays to be
allocated on demand, and passed and stored by reference.

32. AHB UVC development concepts

33. AHB Interconnect verification

34. USB2.0 core verification

35. uvm_root: Serves as the implicit top-level and phase controller for all UVM components. Users do not directly
instantiate uvm_root. The UVM automatically creates a single instance of <uvm_root> that users can access via the global
variable, uvm_top.
o uvm_root comes with new(), get(), run_test(), run_global_phase() and stop_request()

36. uvm_report_info/warning/error/fatal are available anywhere the uvm_pkg routines have been imported

37. `uvm_info/warning/error/fatal*() macros automatically adds the file name and line numbers to the reported
messages. This is the reason why these are preferred over uvm_report_info/warning/error/fatal methods.

38. Different ways to end test in UVM


o global_stop_request(): This calls uvm_top.stop_request used to terminate the active stage if there is no raised
objections
o set_global_timeout() : This does uvm_top.phase_timeout = timeout. Default value being 9200 seconds. If the
phase_timeout is reached without any global_stop_request call, test will exit run phase with UVM_ERROR.
o set_global_stop_timeout(): does uvm_top.stop_timeout = timeout

39. Command line arguments are processed using uvm_cmdline_processor class


o Instance-specific factory override +uvm_set_inst_override
o Type-specific factory override +uvm_set_type_override
o Integer configuration +uvm_set_config_int
o String configuration +uvm_set_config_string
o Timeout +UVM_TIMEOUT
o Max quit count +UVM_MAX_QUIT_COUNT
o Objection mechanism debug +UVM_OBJECTION_TRACE

Potrebbero piacerti anche