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.

Advanced SystemVerilog Process Control – Beyond fork-join_X

The below link explains the process control with "process" class handle.

http://learn-systemverilog.blogspot.in/2010/07/advanced-systemverilog-process-control.html