How class based uvm test top connected in module

When import the uvm package in module, the task run_test(string testname="") will be visible as global task from the file uvm_globals.svh  

This task is a Convenience function for uvm_top.run_test() , it calls uvm_root class run_test which creates the test class object and manages/spawns uvm phases.

UVM_ROOT:

The ~uvm_root~ class 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 (uvm_pkg-scope) variable, ~uvm_top~.

A better theory for System Verilog threads 

Follow this article and gives a good explanation that I ever saw

http://www.arrowdevices.com/blog/oops-3-issues-that-show-system-verilog-threads-are-not-oop-safe/

The "wildcard bins" in SV useful for covering addresses/register coverage with specific

 This is useful in finding register bit specific coverage
 If reg1 is a 32 bits wide and we were interested in LSB [3:0] in combine with msb [31]=1

  REG1_BITS_CP : coverpoint reg1 {  
                                     wildcard bins ={32'b1000_0000_0000_0000_0000_0000_0000_????};
                                 }

So with this cover point you will get  16 bins ,32'b1000_0000_0000_0000_0000_0000_0000_0000,32'b1000_0000_0000_0000_0000_0000_0000_0001 to 32'b1000_0000_0000_0000_0000_0000_0000_1111.

shallow copy vs deep copy

Packet p1;
Packet p2;
p1 = new;
p2 = new p1;//shallow copy
The last statement has new executing a second time, thus creating a new object p2, whose class properties
are copied from p1. This is known as a shallow copy. All of the variables are copied across integers, strings,
instance handles, etc. Objects, however, are not copied, only their handles; as before, two names for the
same object have been created. This is true even if the class declaration includes the instantiation operator
new.
It shall be illegal to use a typed constructor call for a shallow copy (see 8.8).
A shallow copy executes in the following manner:

1) An object of the class type being copied is allocated. This allocation shall not call the object’s constructor
or execute any variable declaration initialization assignments.
2) All class properties, including the internal states used for randomization and coverage, are copied to
the new object. Object handles are copied; this includes the object handles for covergroup objects
(see Clause 19). An exception is made for embedded covergroups (see 19.4). The object handle of
an embedded covergroup shall be set to null in the new object. The internal states for randomization
include the random number generator (RNG) state, the constraint_mode status of constraints, the
rand_mode status of random variables, and the cyclic state of randc variables (see Clause 18).
3) A handle to the newly created object is assigned to the variable on the left-hand side.
NOTE—A shallow copy does not create new coverage objects (covergroup instances). As a result, the properties of the new object are not covered.

Several things are noteworthy. First, class properties and instantiated objects can be initialized directly in a
class declaration. Second, the shallow copy does not copy objects. Third, instance qualifications can be
chained as needed to reach into objects or to reach through objects:
b1.a.j // reaches into a, which is a property of b1
p.next.next.next.val // chain through a sequence of handles to get to val
To do a full (deep) copy, where everything (including nested objects) is copied, custom code is typically
needed. For example:
Packet p1 = new;

Packet p2 = new;
p2.copy(p1);
where copy(Packet p) is a custom method written to copy the object specified as its argument into its
instance.

Command line arguments to configure DUT parameters

$value$plusargs (string, variable)

This system function searches the list of plusargs (like the $test$plusargs system function) for a user specified string. If a string is found, the remainder of the string is converted to the type specified in the user string and the resulting value stored in the variable provided. If a string is found the function returns the value 1'b1. If no string is found matching, the function returns the value 1'b0 and the variable provided is not modified.

The user string must be of the form: "'plusarg_string''format_string'". The plusarg string is a name followed by either = or + . The format strings are the same as the $display system tasks. These are the only valid ones (upper and lower case as well as a leading 0 forms are valid):

%b - binary conversion
%d - decimal conversion
%e - real exponential conversion
%f - real decimal conversion
%g - real decimal or exponential conversion
%h - hexadecimal conversion
%o - octal conversion
%s - string (no conversion)
%x - (undergound equivalent for %h)

The first string, from the list of plusargs provided to the simuator, that matches the plusarg_string portion of the string specified by the user will be the plusarg string available for conversion. The remainder string of the matching plusarg (the remainder is the part of the plusarg string after the portion that matches the users plusarg_string) will be converted from a string into the format indicated by the format string and stored in the variable provided.

If the size of the variable is larger than the value after conversion, the value stored is zero padded to the width of the variable. If the variable can not contain the value after conversion, the value will be truncated. If the value is negative, the value shall be considered larger than the variable provided. If characters exist in the string available for conversion that are illegal for the specified conversion, the register should be written with the value 'bx.

2. Examples:

<simulator> +FINISH=10000 +TESTNAME=this_test +FREQ=5.6666 +FREQUENCY

// Get clock to terminate simulation if specified.

if ($value$plusargs("FINISH=%d", stop_clock)) begin
repeat (stop_clock) @(posedge clk);
$finish;
end

// Get testname from plusarg.

if ($value$plusargs("TESTNAME=%s", testname)) begin
$display("Running test %0s.", testname);
startTest();
end

// Get frequency from command line; set default if not specified.

if (!$value$plusargs("FREQ=%0F", frequency))
frequency = 8.33333; // 166MHz;

forever begin
#frequency clk = 0;
#frequency clk = 1;
end

This code would have the following effects:

1. The variable 'stop_clock' obtains the value 10000.
2. The variable 'testname' obtains the value 'this_test'.
3. The variable 'frequency' obtains the value '5.6666'; note the final plusarg +FREQUENCY does not affect the value of the variable 'frequency'.

 

Need for abstract class

Prior to SV 1800-2012, abstract classes served two purposes:

1. A partially implemented class - Abstract classes act as expressions of general concepts from which more specific classes can be extended. An abstract class defines some default functionality with virtual methods, and requires you to add additional functionality with pure virtual methods (method prototypes with no implementation). Although the language does not require having a pure virtual method in your abstract class, there is usually no point in using the abstract class without extending it and providing some virtual method overrides. You cannot create an object of an abstract class type; however, you can reference extended objects from an abstract class typed variable. You are using polymorphism to access the virtual method in the extended class, and those virtual methods will access members of the extended class.
2. An interface class containing only pure virtual methods - a completely unimplemented class. This is a way for one class to communicate with another class through a published API that is made up of the pure virtual method prototypes. That one class just needs to contain an abstract class variable to reference the other implemented object. Since SystemVerilog only allows for single inheritance, this also serves to keep the inheritance hierarchies of the two classes separate.

-
The difference between these two contrivances is a matter of degree in implementation inside the base class. However, SystemVerilog 2012 has formalized the concept of interface classes in a way that allows for multiple inheritance of interface classes. These are all concepts borrowed from Java, so you can search for more information in that domain.

why we making an interface as virtual

An instance of a SV Interface (like module in Verilog) is a static object which shall be created during elaboration which is alive throught-out the course of the simulation.
Where as a class object is dynamic which can be allocated memory and can be freed during the course of simulation. So, we cannot instantiate any static objects (let it be interfaces or modules) inside the class.
For that reason, a physical interface is assigned to a virtual interface defined (which is just a handle) inside a monitor/driver class through which you can access the real interface signals.