UVM Qus 1 PDF
UVM Qus 1 PDF
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: 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.
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: 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: 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: 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: 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: 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: 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.
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: 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.
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: "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 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: 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.
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)