Disabling Threads in SystemVerilog: Be careful while using it…!!!

Many times we need to disable the active threads spawned by the fork. But while disabling a fork, one should always be careful, as it can cause an unexpected behaviour. This article explains the unexpected behaviour of disabling a fork, using the different scenarios.

Here, We have two threads, executes parallelly using fork-join_any and our intention is to disable a fork after completion of Thread 1.

Example 1] Disable fork and Disable label with single object of a class

Let’s start with a simple example, where we have a fork-join_any inside a class, which executes two threads parallelly. As in below example 1, a fork is disabled once Thread 1 is completed. This example will produce the same output if we use “disable kill_me” instead of “disable fork” at line number 9, where “kill_me” is a label of the fork (see line number: 4), which we want to disable.

For a single object of a class, “disable fork” and “disable label” works fine. But what if the class has multiple objects. Let’s see in the following examples (2 and 3).

Example 2] Disable fork with two objects of the class

Here, the code in example 1 is modified for the two objects of the class. In the class disable_fork, an additional variable “obj_id” is taken to identify that the main method inside the class is called using which object.

By looking at the output on the above image, both the objects complete Thread 1 and then disable their “own” fork. What if we use “disable label” (here, a label is kill_me) instead of disable fork?

Example 3] Disable label with two objects of the class

Here, at line 15, the “disable fork” is replaced by “disable kill_me”.

Oops, the “disable kill_me” of object 0 has also killed the fork of object 1. This is not the output we were expecting.

So, after looking at all the three examples, it seems that “disable fork” is safer than “disable label”. But “disable fork” is really safe in this context…..??? Let’s see Example 4.

Example 4] Disable fork with multiple forks in the same task

Here, we have added one more fork (join_none) in the main() task of the class. This new fork should not be disabled.

But, when we use disable fork, then it disables all the forks in the current scope.

From examples 3 and 4,

1. if we use “disable label”, then it is visible across all the objects of the same class, so it disables all the forks with the same label in the different objects.
2. If we use “disable fork”, then it disables all the forks in the current scope.

This problem is resolved in example 5.

Example 5] Safest way to use the disable fork

Here, we have wrapped the fork “kill_me” inside another fork-join.

Conclusion:

Always use an additional fork to wrap-up all the forks, you want to diable. This is a safe way, as it limits the scope of a disable fork.

P.S.: Please follow the below link if you want to play with all these five examples 🙂

EDAPlaygound_disable_fork

Why is always block not allowed in Program Block?

The program block came from the Vera verification language that was donated to SystemVerilog. In Vera, a program was a single procedure that represented the “test”. Your test was started at time 0 and when the test terminated, the program terminated the simulation. If you needed multiple test threads, you either had to use the fork statement to start it, or use multiple programs. When the last program terminated, the simulation terminated.

As part of the integration with SystemVerilog, the program was turned into a module-like construct with ports and initial blocks are now used to start the test procedure. Because an always block never terminates, it was kept out of the program block so the concept of test termination would still be there.

Today, most people do not utilize this termination feature because the OVM/UVM have their own test termination mechanisms. The program block is no longer a necessary feature of the language other than to help people converting over from Vera to SystemVerilog.

See my blog: Are Program Blocks Necessary?

– Dave Rich

Ref: https://verificationacademy.com/forums/systemverilog/why-system-verilog-does-not-allow-always-block-program-scope

Automatic Storage

Output:

Pass by Ref

Ref: System Verilog For Verification – Chris Spear, Greg TumBush

=> In SystemVerilog, you can specify that an argument is passed by reference, rather than copying its value. This argument type, ref, has several benefits over input, output, and inout.

1. Increased performance

=> you can pass an array into a routine, here one that prints the checksum.

=> SystemVerilog allows you to pass array arguments without the ref direction, but the array is copied onto the stack, this is an expensive operation.
=> Always use ref when passing arrays to a routine for best performance. If you don’t want the routine to change the array values, use the const ref type, which causes the compiler to check that your routine does not modify the array.

Note: The SystemVerilog LRM states that ref arguments can only be used in routines with automatic storage. If you specify the automatic attribute for programs and module, all the routines inside are automatic.

2. A task can modify a variable and is instantly seen by the calling function.

=> The data argument is passed as ref, and as a result, the @data statement triggers as soon as data changes in the task. If you had declared data as output, the @data statement would not trigger until the end of the bus transaction.

=> In other words, In exa 3.12, in initial block, the bus_read task and thread 2 are parallelly executed in fork-join loop. Thread 2 waits for a data change. In the bus_read task, data is changed inside a blue circle.

If data’s direction was not ref (it was not pass by ref), in that case, the bus_read task would be executed completely and after negedge of bus_grand, the thread 2 would get a changed value of data

But here data is passed by ref, so once data is assigned a value as in blue circle in bus_read task, at a time, thread 2 will get a changed value of data. It will not wait for completion of bus_read task.

Streaming Operators

Ref: System Verilog For Verification – Chris Spear, Greg TumBush

When used on the right side of an assignment, the streaming operators << and >> take an expression, structure, or array, and packs it into a stream of bits. The >>

The >> operator streams data from left to right while << streams from right to left, as shown in Sample 2.51.

You can also give a slice size, used to break up the source before being streamed. You can not assign the bit stream result directly to an unpacked array. Instead, use the streaming operators on the left side of an assignment to unpack the bit stream into an unpacked array.

You could do the same operations with many concatenation operators, {}, but the streaming operators are more compact and easier to read.

If you need to pack or unpack arrays, use the streaming operator to convert between arrays of different element sizes. For instance, you can convert an array of bytes to an array of words. You can use fixed size arrays, dynamic arrays, and queues.

Sample 2.52 converts between queues, but would also work with dynamic arrays. Array elements are automatically allocated as needed.

Note: A common mistake when streaming between arrays is mismatched array subscripts. The word subscript [ 256 ] in an array declaration is equivalent to [ 0:255 ], not [ 255:0 ]. Since many arrays are declared with the word subscripts [ high:low ], streaming them to an array with the subscript [ size ] would result in the elements ending up in reverse order. Likewise, streaming an unpacked array declared as bit [ 7:0 ] s rc[255:0] to the packed array declared as bit [ 7:0 ] [ 255:0 ]. Likewise, streaming an unpacked array declared as bit [ 7:0 ] s rc[255:0] to the packed array declared as bit [ 7:0 ] [ 255:0 ] dst will scramble the order of values. The correct declaration for a packed array of bytes is bit [255:0] [7:0] dst.

You can also use the streaming operator to pack and unpack structures, such as an ATM cell, into an array of bytes. In Sample 2.53 a structure is streamed into a dynamic array of bytes, then the byte array is streamed back into the structure.

SV interview question 3. How to choose a random element from the associative array?

To randomize elements for Fixed arrays, Queues, Dynamic Array and Associative Array:

$urandom_range($size(array) – 1);   or   $urandom_range(array.size() – 1);

For Associative array, it’s not easy to pick up a random element, as elements are stored in sparse manner.

We can use the below code to choose a random element in an associative array.

module main();
int assoc_array[int] = ‘{0:100, 1:200, 5:300, 15:400, 50:500, 1000:600};   // Assign values 100,200,300,400,500 at index 0,1,5,15,50,1000, respectively

int element_num, count, indx;

initial begin
element_num = $urandom_range(assoc_array.size()-1);
$display();
$display(“find %0d%0s element from total %0d elements”,element_num,((element_num==1)? “st”:((element_num==2)? “nd”:((element_num==3)? “rd”:”th”))),assoc_array.size());
foreach(assoc_array[i]) begin
if(count++ == element_num) begin
indx = i;
break;
end
end
count = 0;
$display(“The %0d%0s element is: %0d at index = %0d”,element_num,((element_num==1)? “st”:((element_num==2)? “nd”:((element_num==3)? “rd”:”th”))),assoc_array[indx],indx);
end
endmodule

Result:

find 2nd element from total 6 elements

The 2nd element is: 300 at index = 5

find 0th element from total 6 elements

The 0th element is: 100 at index = 0

SV interview question 2. Specify a width of address line to cover all the locations of a memory block of 8KB. (1 address for 1 byte)

We can calculate the address width of memory block using a system verilog function “$clog2()“.

The $clog2() function returns the number of address bits needed for a memory size. This function calculates the ceiling of log base 2.

For 8KB memory,  2^13=8192 bytes, means we need 13 bits for 8KB memory.

We can get address width using $clog2() function as shown in below example.

Example:

module main();
       parameter MEM = 8192;                          // 8KB Memory
       parameter address_width = $clog2(MEM);
       bit [address_width-1:0] addr;

       initial $display(“address_width = %0d”,address_width);
endmodule

Result: address_width = 13

SV interview question 1. Difference between $display and $monitor

=> $display is used to display values of string, variables or expressions while $monitor is used to monitor a signal when its value changes.

The main difference between $display and $monitor is:

=> We need to call $display every time when we want to print values, but in the case of $monitor, we need to call it only one time, and it will print a value of a variable every time when its value is getting changed.

Example:

module main();
    int i,j,var1;
    initial begin
        #1;
        $display(“second display: value of i is %0d while j is %0d”,i,j);
        $monitor(“second monitor: value of i is %0d while j is %0d”,i,j);
    end
    initial begin
        $display(“first display: value of i is %0d while j is %0d”,i,j);
        $monitor(“first monitor: value of i is %0d while j is %0d”,i,j);
    end
    initial begin
        j=0;
        repeat(10) begin
            i <= var1;
            j++;
            #5;
            var1 = $urandom_range(1,50);
            if(j==4) $monitoroff;               // Switch off monitoring
            if(j==8) $monitoron;               // Switch on monitoring
        end
    end
endmodule

Output:
first display: value of i is 0 while j is 0
first monitor: value of i is 0 while j is 1
second display: value of i is 0 while j is 1
second monitor: value of i is 0 while j is 1
second monitor: value of i is 4 while j is 2
second monitor: value of i is 20 while j is 3
second monitor: value of i is 11 while j is 4
second monitor: value of i is 27 while j is 9
second monitor: value of i is 26 while j is 10

=> From the result of the above example, it’s seen that:

1. $display prints values of i and j only when it’s called
2. $monitor prints values of i and j every time, when their values are getting changed
3. Only one monitoring list can be active at a time. If there is more than one $monitor statement in your simulation, the last $monitor statement will be the active statement.
4. Monitoring can be on or off using $monitoron or $monitoroff statements, respectively.

Abstract/Virtual Class in System Verilog

The need for abstract classes is that you can generalize the super class from which child classes can share its methods.

When different classes have need few common set of properties/ methods (that they can use /override), the concept of virtual/abstract class comes in to picture.

The virtual class can not be instantiated. They just can be extended from number of useful classes, so they can use these generalized methods.

We can encapsulate base class by declaring it as a virtual so it doesn’t let anyone to use this class except its extended classes.

Example:

virtual class mobile; // virtual class. can’t be instantiated. can be accessed by sub-classes

    virtual function mobile_type();  // virtual function. override by child classes

    endfunction

    virtual task features();  // virtual task. override by child classes

        string model;

        int camera_MP;

    endtask

endclass

class micromax extends mobile;   //child class

     function mobile_type();

         $display(“Its a Micromax”);

     endfunction

     task features();

         string model;

         int camera_MP;

         model = “CANVAS MUSIC”;

         camera_MP=5;

     endtask

endclass

 

class samsung extends mobile;   // child class

     function mobile_type();

         $display(“Its a SAMSUNG”);

     endfunction

     task features();

         string model;

         int camera_MP;

         model = “Galaxy Grand”;

         camera_MP=8;

     endtask

endclass

Polymorphism in SystemVerilog

Polymorphism is derived from Greek word, where “Poly” means many and “morph” means forms. i.e. it’s an ability to appear in many forms.

 

The OOPS term for multiple routines sharing a common name is “Polymorphishm”. Polymorphism allows the use of super-class handle to hold sub-class object and to access the methods of those sub-classes from the super-class handle itself.

 

To achieve this, functions and/or tasks in SV are declared as virtual functions/tasks to allow sub-classes to override the behavior of the function/task. So we can say, Polymorphism = Inheritance + virtual method.

 

Example:

 

class vehicle;  // Parent class

    virtual function vehicle_type();  // Virtual function

        $display(“vehicle”);

    endfunction

 

    virtual task color();  // Virtual task

        $display(“It has color”);

    endtask

endclass

 

class four_wheeler extends vehicle;   //child class

     function vehicle_type();  

          $display(“Its a four wheeler”);

     endfunction

 

     task color();

         $display(“It has different colors”);

     endtask

endclass

 

class BMW extends four_wheeler;   // “grand” child class

     function vehicle_type();

         $display(“Its a BMW”);

     endfunction

 

     task color();

         $display(“It is Black”);

     endtask

endclass

 

program polymorphism;   // program block

    initial begin

       vehicle vehcl;

       four_wheeler four_whlr;

       BMW bmw;

    

       four_whlr=new();

       bmw=new();

 

       vehcl=four_whlr;   // No need to create a object by calling a new method 

       vehcl.vehicle_type();   // accessing child class method by calling base class method

 

        vehcl=bmw;        

        vehcl.vehicle_type();   // accessing “grand” child method by calling base class method

        four_whlr=bmw;

        four_whlr.color(); // accessing “grand” child method by calling child class method

   end

endprogram

 

Output:

    Its a four wheeler

    Its a BMW

    It is Black