- what is UVM?
- UVM is a universal verification methodology, it consists of base classes,
macros, utility classes and set of guidelines on how to do everything of
testbench, which includes TB architecture, testcase coding, component coding,
connections, implementing various phases of components, etc.
- it is pre implemented base classes, macros and policy classes.
$display(“ERROR : tx failed”);
`uvm_error(“id”, “tx failed”);
- what are the advantages of UVM?
- set of guidelines that every engineer is aware, it helps new engineer ramp
up quickly on TB evnrionment
- set of base classes and macros which implement lot of common functionality,
we use those to develop actual TB commponents.
- It helps with reusability and modularity
- Utility classes(factory, config_db, resource_db) to easily configure
Testbench structure, it can be done from testcase
- it has policy classes to take care of various TB requiremnets, like
printing, comparing, recording, packing, etc
- in built methods to implement pack, copy, compare, print,unpack, clone
- what is factory in UVM?
- factory is utility class in UVM, in to which all compoentns and object
definitions are registered. User will access factory definition to create
the instance of these registred components or objects.
class ahb_driver extends uvm_driver#(ahb_tx);
`uvm_component_utils(ahb_driver) //ahb_driver is registered in to factory
- How to we create a component instance using factory defintion?
drv = ahb_driver::type_id::create(“drv”, this);
- How to we create a component instance using SV file definition?
drv = new(“drv”, this);
- Benifits of factory in UVM?
- it is globally accessible throughout the TB
o it will prints all the changes
- What is factory registration?
- it is a UVM concept where a compoennt or object class definition is added in
to uvm_factory using uvm_component_registry or uvm_object_registry. Essentially
this is the another copy of compoent/object class definition.
- What is the difference between uvm_component and uvm_object?
- uvm_component is used to create the TB component which gets created at 0 simulation time and exists till the end of simulation.
ex: driver, generator, monitor, etc
- uvm_object is used to create the TB stimulus/scenario which gets created during the simulation time and gets deleted as soon as it is used
ex: axi_tx, eth_pkt, apb_tx, etc
- What are the benefits of component/object factory registration?
- these registered definitions are globally accessible, hence their defintiions can be changed/overriden for the current testcase requirements
- when component/object is registered to factory, its fields can also be
registered, which automatically implements methods like print, copy,
compare, clone, pack and unpack
- component/object behavior can be changed as per testcase requirements, just
from testcase build_phase itself(without oepning the actual file).
- wherever ahb_driver is used in the TB, its defintion will be changed with ahb_error_driver
- what is objections in UVM?
- objection is a UVM concept used by the components to indicate that their
processes are still running, hence simulation can’t be finished unless those
processes are completed. It is used by raising and dropping of objections.
task run_phase(uvm_phase phase);
repeat(10) drive_tx(tx); //simulation can’t finish while this is happening, since objection is raised
- default timeout: 9200 sec
- what is the typical UVM TB structure?
Testbench top most module -> root -> testcase instance -> top_env instance -> sub_env, scoreboard, register model ->(sub_env) -> master agents &/or slave_agents -> driver, Sequencer, monitor, coverage
- what is uvm_root? significance in UVM TB?
- it is similar to program block in SV, but much more features implemented
- it is the component which holds the complete TB definition
- it keeps track of objections raised and dropped using uvm_phase phase
passed to all the components
- it has in built way of calling uvm_cmdline_processor to read the user
command arguments automatically
vsim work.top +UVM_TESTNAME=ahb_10_tx_test
I don’t need to write $value$plusargs(“UVM_TESTNAME=%s”);
above will be read automatically
vsim work.top +num_txs=10
I need to write $value$plusargs(“num_txs=%s”); since num_txs is not a stanard UVM concpet
- it automatically calls various phases of UVM starting from build_phase,
connect_phase, end_of_elaboration_phase, start_of_simulation_phase,
run_phase, extract_phase, check_phase, report_phase
- what are the various UVM phases?
- all the phases except of start_of_simulation_phase and run_phase are
- Why UVM build_phase is top-down?
- top-down appraoch makes sure that upper component memory(parent) is
allocated before child memory can be created
- what parent & children in UVM?
for test : parent: uvm_root, children: env
for env : parent: test(uvm_test_top), children: sub_env’s
for sub_env : parent: env, children: agent’s
- how UVM enviroenment is started?
top most module:
run_test(“ahb_10_tx_test”); //we are starting ahb_10_tx_test
//it will automatically start running all UVM phases one by one.
- which is the only phase where objections can be raised and dropped?
- what are the different ways to specify which testcase we want to run?
- a. pass it as command line argument
vsim work.top +UVM_TESTNAME=ahb_10_tx_test
- b. define the test in run_test arguemtn
run_test(“ahb_10_tx_test”); //we are starting ahb_10_tx_test
//it will automatically start running all UVM phases one by one.
which one is prefered? a
- what is difference between uvm_seqeunce and uvm_seqeunce_item?
- uvm_seqeunce is a UVM base class, used to represent a complete sequecen consisting of various sequence items.
- uvm_seqeunce_item is also a UVM base class, used to represent one individual
tranaaciton(group of these makes up a sequence)
- ex of uvm_seqeunce will be a sequence of 10 ahb tx’s
- ex of uvm_seqeunce_item will be one ahb_tx
- what is TLM in UVM?
TLM stands for Transaction Level Modeling, it is a set of base classes with pre-implmeneted mehtods used to connect various TB components.
- what is the difference between seq_item_port and analysis_port?
seq_item_port is used between driver and sequencer, where communicaton is only 1 to 1
analysis_port is used for 1 to many connections, like monitor to coverage/ckr/ref_model etc
- what is the difference between push model and pull model in TLM?
push model: producer acts as a master of the communication
pull model: consumer acts as a master of the communication
- how TLM differs from mailbox in SV?
- TLM has provision where it can be as a bidirectional communication
- TLM connections are more easier(seemless connection), we don’t need to pass
the handle of any object to a compoent
- there are multiple variations of TLM, which fits in to various requirments.
Mailbox does not provide so many options.
- what are the various types of testcases developed in verification?
- by default every TB will have 2 tests at minimum
- register reset test
- register write-read test
- rest of tests will depend on type of design being verified
o interrupt mapping
o basic funcitonality checks(not exhaustive)
o design suspend and resume tests
o tests to access the design memory space
o perfromance tests
o Module verfiication
o exhaustive funcitonality checks with all register configuration possibiltiies
o basic suspend and resume features
UVM Interview preparation : 18/JAN/2020
- Siliconch : 6L/A
- Atria logic :
- why connect_phase is bottom up?
- this is UVM methodology has been defined
- connect_phase being a function, it gets over in 0 time
- Register abstraction Layer
- Design register equavalent representation in TB
o implemented using UVM register base classes
- m_desired : given a register,
RAL has 5 sets of value for each register:
– dut_value : Value of the register inside the DUT
– m_reset_value : value of the register at reset
– m_desired_value : value of the register, what user thinks it should be
– m_mirrored_value : value that is being mirrored from DUT to TB
INTR Status register:
– keeps track of interrupt status
intr_sts_reg = 32’h1234_5600;
intr_sts_reg.m_desired_value = 32’hABCD_EFGH;
– dut value will be mirrored in to m_mirrored_value
since we are using UVM_CHECK, it will also do the check(comparison of m_mirrored_value with m_desired_value)
- Register layer has 2 types of access
- front door
o write, read, update, mirror
- back door
o peek, poke
poke: write in to the register using register hierarchy path
peek: read from the register using register hierarchy path
– during the register model definition, we would have specified the hierarchy of CSR register
- register test cases
- 4 combinations
- how to end simulation without using $finish and withotut dropping objection?
vsim work.top +UVM_TIMEOUT=1000
default UVM_TIMEOUT value is 9200sec
- vsim work.top +UVM_OBJECTION_TRACE
- if we raised many objections, simulation is hung, how do we know which ojection is causing simulation to hang?
run vsim with +UVM_OBJECTION_TRACE
- where do we use export in TLM1.0?
- export is used where the component is not supposed to consume the transaction, it is supposed to forward the incoming transaction to other port, final consumer is someother block
- lock, grab
Order of execution will be:
SEQ1 -> SEQ4 -> SEQ2 -> SEQ3
sequence1.kill() or sequencer.stop_sequences()
- difference between p_sequencer and m_sequencer?
- both these keywords are used from a sequence perspective
- p_sequencer refers to teh virtual seqeuncer on which curretn sequence should be run.
- m_sequencer refers to master seqeuncer for given non-virtual seqeuence.
ex: seq3, if seq3 is of type axi_10_tx_seq, m_sequencer will be axi_sqr
- p_sequencer comes in to place since we define `uvm_declare_p_sequencer inside the seqeunce code
- difference between config_db and resource_db?
- config_db is a extended class of uvm_resoruce_db
- they differentiate based on how the DB register variables are accessed.
- config_db variables are accessed based on the compoennt hiearchy
- resource_db variables are accessed based on the SCOPE and KEY indepdendet of hiearchy
- is it possibel to set a vairbale in lower heirarhcy in to config_db and get in upper heirarhcy?
- TLM and mailbox differences?
– TLM provides seemless connection
o we don;t need to pass the TLM object handle to any otehr component
– TLM provides bidirection communication models
seq_item_port.get_next_item(req); //item from sqr -> driver
seq_item_port.item_done(rsp); //item from driver -> sqr
– TLM comes with in built methods for diffeent TB requirements
– only provides one-direction communication model
– maiobox will not be suitable for broadcast model
– mailbox requires user to pass the mailbox handle to btoh producer adn consumer
- difference between uvm_report_object and uvm_report_handler?
o all the reporting methods and reporting method manipulation methods are implemented
o keep track of all reporitng reference variables
ex: what is referncer verbosity for magent1.drv
based on these referecen values, it will decide whether to issue the message or not
- additional time for which simulation should run once all raised objectons are dropped
- what are different steps in uvm_do?
- it is implement in 7 stpes
- what is run_test in UVM?
- run_test is global method, which will create the instance of uvm_root as top. It will inturn call the top.run_test method, which will essentially start the uvm_root functionality.
- uvm_resource_db, what is difference b/w read-by_name and read_by_type?
- read_by_name: user has to pass both SCOPE and KEY to retrive the variable from resoruce_db
- read_by_type: user has to pass only SCOPE to retrive the variable from resoruce_db. WHichever is the 1st variable of current data type added in to resoruce_db will be retirved.
ex: usb_reg_model reg_model;
uvm_resource_db#(usb_reg_model)::set(“GLOBAL”, “USB_RM”, reg_model, this);
– we are not going to add any other usb_reg_model in to resoruce_db
– in this case, we can retrive the variable by using read_by_type
uvm_resource_db#(usb_reg_model)::read_by_type(“GLOBAL”, reg_model_i, this);
- when do we prefer resoruce_db over config_db?
- when a variablke should be visible in complete tB hierarchy ireespective of hierarhcy, we prefer to resoruce_db.
- difference b/w uvm_info, uvm_report_info?
- uvm_info is a macro, which inturn calls uvm_report_info.
o uvm_info on top of uvm_report_info, it automatically prints the file name and line number.
- what is type_id?
- type_id is the factory definition of the component/object class. it is of type uvm_object_registry or uvm_component_registry with current class parameterized.
ahb_driver::type_id is the ahb_driver factoruy definition
ahb_monitor::type_id is the ahb_monitor factoruy definition
- platform build around DUT, so that inputs can be applied as per current testcase and output can checked for testcase reqiroments.
- utility class which holds all the compoennt and object defiitions. This is globally accessible so that these defiitions can be changed as per test requirments.
- what is override in UVM? what are different types of overrides?
- override is a concept which enables user to change the factory definition of a given component/object without changing the file definition of the same. This allows user to have a component/object definition for current testcase requirements. Two types of overrides, 1. type override 2. inst override
- type override will change the definition of the component/object for all the instances of the component or object
- inst override will change the definition of the component/object only for specific instances or heirarchies of the component or object
- what is difference b/w create and new?
- create is used for the component/objects which are registered to teh factory
- create inturn calls new function
- new is used for the component/objects which are not registered to teh factory
- why do we pass uvm_phase vairbale with UVM phase methods?
- uvm_phase phase is singleton class which has handle created in uvm_root. passing this variable makes sure that all raise and drop objections can be tracked in uvm_root.
- what is benefit of parent and name in new defnition?
- these will be useful in coming up with complete TB hierarchy and also helps in assigning unqiue instance(full) names to each of the components.
- when user implements a error testcase, test is supposed to fail with uvm_error reporting. But I still want this messages to be changed to lower severity so that testcase will pass. But uvm_report_catcher will report what severity changes have been done and which messages have been changed.
- uvm_report_catcher will work w.r.t testcases.
- every uvm_component based class have set_action method, using which we can change the specific message action levels.
- uvm_component cmp;
cmp = drv;
cmp.buil_phase will still refer to drv method.
- explain sqr-drv communication model?
- sqr-drv communication happens trhough TLM1.0 using seq_item_port and seq_item_export. The methods used for this communication are get_next_item and item_done. get_next_item called by driver to get the item from sqeuence list and item_done is called by drv to indicate that current item has been processed.
- what is diffeence b/w uvm_tlm_fifo and uvm_analysis_fifo?
- benefits of methodology?
- set of very well defined guildelines on how to do every asepct of verification. methodology also provides base classes and macro to do these implementation with minimal effort.
- TB becoems reusable and easy to update for new requiremnts
- easy for new engineer to ramp up.
- concept of TLM?
TLM implements the communicaiton between 2 components, one producing and other consuming. One fo these compoennts calls a method and otehr compoennt implement this method, though this mehtod call tx gets passed from one compoennt to anotehr.
- mechanism of a components to know whether its descendants are actively running or hung in simulation. Descendants have to raise an objection, to indicate its active status.
- What is clocking block? how it helps avoid possible race conditions between design and TB?
Clocking block is a langauge consturct defined as part of interfaces for aceiving synchoronization between design and TBs.
It uses cocnept of input skew and output skew for achievie the synchoronization.
output skew indicates how much time after +edge of the clock, design inputs should be driven(BFM will drive these inputs). Since BFM is driving these signals, this skew is called as output skew. This concept makes sure that design gets most stable input value.
INput skew indicates how much time before +edge of the clock, design output should be sampled(BFM will sample these). Since BFM is sampling(collecting) these signals, this skew is called as input skew. This concept makes sure that BFM(TB) gets most stable values of design output.
hence clocking blocks makes sure the stable values of design inputs and outptus are driven/sampled by using outptu and input skews.
2 kinds of interfaces:
o all signal driving and sampling has to be synchornous w.r.t to some signal(generally that some signal is called as clock)
o two types of signals at every interface
o input : need to be driven in to the design
o inputs are driven by BFM => for BFM signals are output, when is the best time to drive
o when is the write time to drive?
this delay after which we want to drive the design inputs is called as output skew.
clocking master_cb@(posedge clk);
output #2 addr; //2 units after #edge of clock address should be driven
output #3 wdata; //2 units after #edge of clock address should be driven
– best time drive the design inputs is just after the +edge of the clock.
o output: need to be sampled by teh TB
BFM needs to sample these outputs
when it best time to sample?
amount of time before the +edge of the clock when design outputs should be sampled, is called as input skew.
o skew’s are being discussed here from BFM perspective.
o input skew: how mucj time before +edge of clock to sampel design outputs
o output skew: how mucj time after +edge of clock to drive design inputs
o CLOCKING BLOCK: drive design inputs in such a way that it gets most stable values. Sample design outputs in such a way that we get most stable outputs from the design.
o there is no clock on these interfaces.
o Driving/sampling will happen purely based on delays.
- What is the difference between parameter and macro? which one is preferred?
- parameter values for specific module gets set at elaboration time.
- macros values are set during compilation time.
- both of them are used for replacing hardcodes values with KEYWORDS
o in terms of flexibility of using values in different modules, parameter is preferred.
o in terms of defining a complex code, macro is preferred(parameter can’t do this)
o macro does not just define values, it also can a complete piece of code in to single KEYWORD
- what is the signifniance of uvm_root in UVM based TBs?
- it is the starting point of TB(similar to program block in SV based TB)
- it automatically enables cmd line processor to read all UVM elaboration time arugments
- it figures out the testname to run
- it creates test as uvm_test_top
- it builds the complete TB
- it run all the components UVM phases starting from build_phase to report_phase one after other
- it also keeps track of objections raised and dropped, based on that it will decide when to end the simulation
- it defines a varibale called phase, which is passed to all the components as different phase arguemnts, through that it keeps track of objections.
- what is starting_phase in UVM?
- starting_phase is a uvm_phase variable defined in uvm seqeucnes for rasiing and dropping objections while seqeunce is being executed by the seqeuncer. This is required since seqeunce is an uvm_object based class, it does not have phase keyword for raising and dropping objections. In this case, we set starting_phase by mapping seqeucne to run in a specific phase of the sequencer as part of test build_phase. That phase is what gets assigned to starting_phase.
- starting_phase phase is used in pre_body and post_body for rasiing and dropping obejctions, to ensure that simulation completes only after all the items of the seqeunce have been driven to the design.
uvm_config_db#(uvm_object_wrapper)::set(this, “env.agent.sqr.main_phase”, “default_sequence”, ahb_wr_10_seq::get_type());
main_phase becoems starting_phase for env.agent.sqr executing ahb_wr_10_seq sequence.
- what is difference between aligned and unaligned transfers?
- aligned transfers are the type of transfers where starting address is multiple of beat size. It indicates that transfer is alinged with the beat boundary.
to put it in equation: addr%(2**size) == 0 => then it is aligned, else unaligned
- what is TLM? what are the different connection types in TLM1.0?
- TLM stands for transaction level modeling. it is used in UVM based TB for estabilishing connection between a producing componetn and a consuming component. TLM is implemented using port, export and imp concept. There are 4 types of conneciton models: push, pull, FIFO and broadcast models.
- what are the types of overrides in UVM? how override helps in UVM TB?
- there are 2 types of overrides, type override and instance override. These overrides can be done by name and by type. These override apply to the factory definitionition of a component or object. Inst override will only apply the changes specific to few heiarchies and type overrides apply changes to the complete TB hiearchies.
- How override helps?
o Override makes sure that we are able a change speicifc component/object definition without actually opening the file and changing its code. It can be done in test build pahse, hence it gives flexbility to use defintions of compoents & object specific to per testcase requiremnts.
- what is the difference between new and create?
- new is SV construct defined in a class for the object memory allocation. It uses the SV file class definition for creating object. Create is a method defined as part of component/object factory definition to create the object as per factory definition. create in turn calls new to create the object. Only difference it uses the latest defintion that is availbaile in the factory.
- explain the communicaiton between driver and seqeuncer?
- communicaiton happens using TLM. Driver has seq_item_port and sequencer has seq_item_export. Driver calls get_next_item, which is implemented in seqeuncer. Communciatingcation happens using get_next_item adn item_done method calls.
- what are the benefits of factory registration?
- factory is globally accessible, so component/object definitions can be changed as per the testcase specific requrements
- factory comes with different types of overrides to change the deifnition specific to testcase
- factory registration also create the different coenvinicen methods in tx class.
- required for automatic config_db variable retrieval.
11. what are the different steps in uvm_do macro?