Tuesday, 2 February 2016

Explain about run_test() in UVM



Execute all component’s all registered phases.
If the optional test_name argument is provided, or if a command-line plusarg, +UVM_TESTNAME=TEST_NAME, is found, then the specified component is created just prior to phasing.
The test may contain new verification components or the entire test-bench, in which case the test and test-bench can be chosen from the command line without forcing recompilation.
If the global (package) variable, finish_on_completion, is set, then run_test will call $finish after all phases are executed.

  1. Take string name from plusarg (+UVM_TESTNAME ) or its own argument ,
    1. if ($value$plusargs("UVM_TESTNAME=%s", test_name)) begin
  2. Create uvm_test_top using below command
    1. $cast(uvm_test_top, factory.create_component_by_name(test_name, "", "uvm_test_top", null));
  3. Call m_run_phases of uvm_phase class,
    1. Which execute all registered phases of all componenets in pre-defined order.
  4. Wait for all phases to be completed,
  5. If the global (package) variable, finish_on_completion, is set, then run_test will call $finish after all phases are executed.
    1. By-default finish_on_completion bit is set to 1 only

Reference:
1) uvm_root.svh file from uvm source code
 

create() vs new() in UVM



Create() is a factory method which construct an object. To override an object you need to construct it using create(). if you use set_type_override before run then,factory replaces constructed object with derived object( specified in override).
if you use new() then you can’t override. 

You should always use create() rather than using new() for classes registered with the factory.

Example:
Coming soon...

Advantages of UVM



UVM is a SystemVerilog class library explicitly designed to help you build modular reusable verification components and test-benches. It is an industry standard so you can acquire UVM IP from other sources and use them in your environment. If you don't use UVM, you'll have to build everything yourself from scratch.

Sequence methodology gives good control on stimulus generation.  There are several ways in which sequences can be developed which includes randomization, layered sequences, virtual sequences etc which provides a good control and rich stimulus generation capability.

Separating stimulus generation from Test-benches – Tests in terms of stimulus/sequences are kept separate from the actual test-bench hierarchy and hence there can be reuse of stimulus across different units or across projects.

Factory mechanisms simplifies modification of components easily. Creating each components using factory enables them to be overridden in different tests or environments without changing underlying code base.

Configuration management: Config mechanisms simplify configuration of objects with deep hierarchy. The configuration mechanism helps in easily configuring different test-bench components based on which verification environment uses it and without worrying about how deep any component is in test-bench hierarchy.

UVM Phases provides control over simulation behavior in a systematic way and execute in sequential order to avoid Race condition.

Modularity and Re-usability (using TLM over mailbox) – The methodology is designed as modular components (Driver, Sequencer, Agents, Env etc.)  Which enables reusing components across unit level to multi-unit or chip level verification as well as across projects.
Advantages of TLM over mailbox:
Let's say you have two components: A and B. Component A has a thread doing puts and component B has a thread doing gets. They are both connected through a common mailbox which means they both must declare handles to a matching mailbox type. This creates an unwanted dependency. At some point, I might want some other component other than a mailbox to connect to, like some kind of arbitrator. So I would have to modify the handles types in the components.