0% found this document useful (0 votes)
59 views5 pages

UVM Qus 1 PDF

The document contains frequently asked questions (FAQs) about universal verification methodology (UVM). It discusses concepts like factory automation, super classes, objections, phases (build and run), macros, imports vs includes, configuration databases, virtual interfaces, sequences vs sequence items, randomization, and differences between various UVM constructs like components, objects, ports and more. The FAQs provide concise explanations of these essential UVM concepts.

Uploaded by

Sam Honey
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
59 views5 pages

UVM Qus 1 PDF

The document contains frequently asked questions (FAQs) about universal verification methodology (UVM). It discusses concepts like factory automation, super classes, objections, phases (build and run), macros, imports vs includes, configuration databases, virtual interfaces, sequences vs sequence items, randomization, and differences between various UVM constructs like components, objects, ports and more. The FAQs provide concise explanations of these essential UVM concepts.

Uploaded by

Sam Honey
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Universal Verification Methodology FAQ

Q: What is factory automation? How is it different in building a conventional SV testbench


A: The factory is a mechanism that gives you more flexibility when instantiating components in the
verification environment or generating stimulus. The factory allows you to override the types of objects
that are created by existing verification code without needing to modify the original source code.

Q: what is the super class of the current class?


A: The super-class is the class that the current class "extends". So the super class of my_test is uvm_test

Q: what is raise_objection and drop_objection in run_phase


A: This is the mechanism to end the test. A piece of UVM code raises an objection whenever it is busy
(so the test does not end too soon) and drops the objection again when it is ready to end.

Q: why we can’t print any statement and raise objection in build phase?
A: You can print stuff in build_phase. It does not make sense to raise objections in build_phase, because
objections are only meaningful in run-time phases where simulation time is passing.

Q: as build_phase and run_phase uses uvm_phase, can i write the run_phase task in the
build_phase ?
A: No. These are pre-defined "common" phases that have to be used for predefined purposes. build_phase
builds the UVM component hierarchy, run_phase in effect "runs simulation", i.e. simulation time passes.

Q: what is the advantage of create over new?


A: When you call new, you get an object of a type that is determined at compile-time according to the
type of the variable the reference is assigned to. The point of the factory mechanism is to allow you to
override the type of the object being created at run-time.

Q: Why do we need to include uvm_macros, and import uvm_pkg separately?


A: Just a technicality of SV. "import" is used to import names from a package, "include" is including the
contents of a text file that contains some macro definitions. In other words, "import" cannot be used to
make macros available

Q: whu macros lib called outside package and uv_pkg call inside the package, as both are library
file ?
A: Because include is just copying text around, whereas import is manipulating the names in some
"namespace". With import, you want to restrict the scope of the imported names. When including macros,
you don't have that luxury because macro definitions are compiler directives.

Q: is it necessary to import uvm_pkg in both top module and my_pkg?


A: uvm_pkg contains all the UVM definitions (except for macros), so you need to import it wherever you
use any UVM definitions.

Q: what happens to the new constructor in my_test when run_test(:my_test") is called ?


A: run_test("my_test") uses the UVM factory to locate the actual test object, which it then starts as the
top-level test.

Q: what if i don't give a drop objection at the end?


A: The test only ends when all objections have been dropped. However, you can also set a time-out, or
you can "crash out" of the test by causing a fatal error (`uvm_fatal(...))

This study source was downloaded by 100000761691277 from CourseHero.com on 12-20-2023 10:53:37 GMT -06:00

https://www.coursehero.com/file/29151154/UVM-Qus-1pdf/
Q: what is mean by UVM_Drain_Time?
A: The drain time is an extra bit of time allowed after all objections are dropped before simulation ends.

Q: Any example of uvm component path hierarchy for scope?


A: E.g. "*.m_env.m_agent.m_driver"

Q: Is drop objection a blocking kind of a statement? e.g i have raised two objections in the order of
objection1 followed by objection2 but i drop the objection in the order of objection 2 followed by
objection 1
A: No, drop_objection is not blocking.

Q: why is the interface declared virtual?


A: An "interface" is the definition of a structural component, much like a module. A virtual interface is, in
effect, a reference to an interface instance. The virtual interface is used to pass data between structural
Verilog modules and the class-based verification environment.

Q: can uvm_config_db be used to retrive parameters in object class instead of component class?
A: The VALUE that is stored in the config_db can be of any type at all (bit, int, string, uvm_object,
uvm_component, ...). The SCOPE in the config_db is a test string that represents a path through the UVM
component hierarchy.

Q: how are the characteristics of the interface signals conveyed to the driver?
A: Through the virtual interface, which is just a reference from the driver to the SV interface instance.
The driver can "see" the variables and wires in the interface through the virtual interface

Q: what is finish_on_completion?
A: Just a flag to indicate whether or not UVM will call $finish at the end of the test (after the final UVM
phase has executed)

Q: The raise/drop can be done only in test?


A: raise/drop would typically be called from a test, from a sequence, or from a driver. They can be called
from anywhere

Q: What happens if finish_on_completion == 1


A: $finish is called on completion of the test

Q: how driver know when to pull the transactions from the sequencer?
A: The driver will try to grab the next transaction just as soon as it is finished with the previous
transaction (or even before that if dealing with pipelined transactions)

Q: How it will differ uvm_sequence and uvm_sequence_item


A: A sequence is best thought of as a sequence of transactions. A sequence_item can be a single
transaction (or another Sequence)

Q: For constrained random variables, is it possible to use a seed to obtain many times the same
random sequence?
A: Yes, definitely. UVM has random stability (the ability to generate the same random sequences after
making changes to the code) built-in. You would just set the SV seed on the command line.

This study source was downloaded by 100000761691277 from CourseHero.com on 12-20-2023 10:53:37 GMT -06:00

https://www.coursehero.com/file/29151154/UVM-Qus-1pdf/
Q: what is difference between uvm_component_utils and uvm_component_utils_begin followed by
uvm_component_utils_finish
A: The *_begin and *_end forms bracket a bunch of field macros, which perform some automation on the
fields within the component.

Q: Should we write individual Score boards for the every module of a SOC or only one is enough
for overall SOC? Which is the best practice?
A: The answer depends on your application. Scoreboards are generally concerned with end-to-end tests,
e.g. sending packets to the DUT through one interface and getting them back through another interface,
but in general a scoreboard can do whatever you want it to do. This is a challenging subject, because it is
very difficult to give general guidelines.

Q: what is the difference between sequencer and sequence


A: A sequencer is a UVM component, built during the build_phase. A sequence generates a bunch of
transactions during the run phase

Q: How we will connect driver and sequencer, if both class driver and sequencer is extended by
uvm_component class?
A: When you connect components, you are connecting individual objects, not classes. So you connect one
instance of uvm_component (the driver) to another (the sequencer)

Q: What is the difference between analysis port and Imp ports?


A: A port is used to call functions up/out of a component. An imp is a variation on an export, used to
receive incoming function calls.

Q: already addr, data are decalred as rand then why need to use seq.randomize?
A: It is the call object.randomize that actually randomizes any variables within the object that are declared
with the rand keyword.

Q: what is the difference between seq_item_port, analysis_port and tlm_port


A: A regular TLM port must be connected to EXACTLY on TLM export. An analysis port is like a
broadcast mechanism, so one analysis port can be connected to any number of exports, including zero.

Q: What does super.new means?


A: It means calling the constructor (new) of the base class (the one the current class is extended
from)

Q: What is $cast(tx, rhs) ?what is the purpose ? is it an UVM construct or SV syntax ?


A: This is a dynamic cast. It is attempting to cast the type of rhs to the type of tx.

Q: what is the difference between copy and clone?


A: Copy copies the contents of some other object over the top of the current object. Clone creates a brand
new object and copies its contents from an existing object. Copy works best in SV (because of some
technical limitations of OOP in SV)

Q: difference b/w uvm_component and uvm_object?


A: Components are organised into a component hierarchy. uvm_object is the base class for (almost)
everything in UVM

This study source was downloaded by 100000761691277 from CourseHero.com on 12-20-2023 10:53:37 GMT -06:00

https://www.coursehero.com/file/29151154/UVM-Qus-1pdf/
Q: The sequence body code you showed did a check for the sequence phase not being null using an
'if' statement. If the result of the check is 'null', then how does this hold off the rest of the sequence
code from beign executed ?
A: This is recommended practice in UVM. starting_phase is a variable that is optionally set by the parent
if it want the child sequence to raise/drop objections. If a parent sequence is dealing with objections itself
it would not set starting_phase, in which case the test if(starting_phase != null) in the child sequence
would clearly do nothing.

Q: For example I want to create 8 sewuence items and in that want to randomize the address and
data fields. Now at the sequencer would it be possible to batch the requests and schedule it before
sending it to the driver?
A: Yes, that would be possible. Just put your 8 transactions into an array, randomize them in advance, and
then pick them out one-by-one within the sequence

Q: can i start multiple agents parallely


A: Yes, that is the normal way things work. All UVM components run in parallel, and all UVM
components can do things.

Q: what is the use of $cast?


A: $cast is just a dynamic type cast (looking at the value in some variable as if it were of a different type)

Q: how do you constrain random()?


A: object.randomize() with { a == b; c > d; }

Q: why main_phase task in testcase is declared as virtual


A: All the standard phase tasks and functions are virtual methods

Q: If transaction is yet not ready then what 'get_next_item ' will do?
A: Wait until the transaction is ready

Q: why run phase is a task while build and connect phase are functions?
A: Because run_phase is the only common phase method that consumes simulation time.

Q: I see the benefits of structuring the testbench into functions/classes of sequence, sequencer,
driver, monitor etc. Still, this can be easily done without UVM. Same holds for assertions and
constraint randomization (right?). So what new feature does OVM brings really to the picture?
A: Re-use, re-use, and re-use. You are absolutely correct that you can do constrained random verification
in any language without something like UVM. The point of UVM is to have a standard way to build re-
usable verification components, test benches, and tests.

Q: what happens with void'(seq.randomize()); where seq represents my sequence object


A: seq.randomize() returns 1 if the worked and 0 if it fails (if there is a constraint conflict). void'(...) just
discards the returned value.

Q: build and connect are called in which simulation phase?


A: build_phase and connect_phase are two UVM phases. They both occur "during simulation" as
opposed to during compilation or elaboration.

Q: In uvm_config_db, the type of parameter passed has to be virtual always?


A: Only in the case where we are passing virtual interfaces through the config_db, not for any other
parameter type.

This study source was downloaded by 100000761691277 from CourseHero.com on 12-20-2023 10:53:37 GMT -06:00

https://www.coursehero.com/file/29151154/UVM-Qus-1pdf/
Q: can you please give one example of overriding the type of the object using factory?
A: old_object_type::type_id::set_type_override(new_object_type::get_type());

Q: What is the use of sequencer?


A: A sequencer is a component that is used to generate test stimulus.

Q: Why we are dropping raise_objection and drop_objection in sequence as it is already done in


test?
A: To make the sequence code self-contained and thus more re-usable.

Q: "A sequencer is a component that is used to generate test stimulus", then what is the sequence
an how it differs from sequencer?
A: A sequencer is a component (think of a processor), a sequence is a set of stimulus (think of a software
program running on that processor)

Q: what is the purpose of factory?


A: The type of the object created by the constructor new is fixed at compile‐time. The point of the factory
pattern (type_id::create()) is to let you override the type of the object being created at run‐time.

Q: what is ovm_test?
A: uvm_test is the base class used when creating user‐defined tests in UVM

Q: why we use create method instead of new() in buitd_phase? can you tell the difference b/w
them?
A: This is a factory method. It allows you to override the type of the object being created, whereas the
type of the object created by new is determined at compile‐time.

Q: what does start_item actually do?


A: Waits for the driver to call get or get_next_item, then returns.

Q: why do you call req.randomize() after start_item? shouldn't req be ready when the driver gets
it?
A: You need to understand the concept of late randomization. The whole point of the start/finish_item
handshake is to delay the randomization of the transaction object until the last possible moment before
releasing it to the driver.

Q: what is the use of monitor?


A: A passive component that watches the pin wiggles on the DUT interface and sends information to the
rest of the verification environment for checking and coverage collection.

This study source was downloaded by 100000761691277 from CourseHero.com on 12-20-2023 10:53:37 GMT -06:00

https://www.coursehero.com/file/29151154/UVM-Qus-1pdf/
Powered by TCPDF (www.tcpdf.org)

You might also like