SESSION 4
Introduction To SystemVerilog
Prepared by Ahmed Eissa
[Link]@[Link]
CONTENTS
• OOP in verification
• OOP in SystemVerilog
Question:
Why did they add OOP in SystemVerilog?
Answer:
Layered Testbench
OOP IN VERIFICATION
module test(pAddr, Pwrite, Psel, PWData, if([Link][16’h50] ==
Penable, Rst, clk); 32’h50)
initial begin $display(“Success”€);
Rst <= 0;
else
$100 <= 1’b1;
$display(“Error”€);
@(posedge clk)
Paddr <= 16’h50; $finish;
PWData <= 32’h50;
PWrite <= 1’b1; end
Psel <= 1’b1;
endmodule
@(posedge clk) Penable = 1’b1;
@(posedge clk) Penable = 1’b0;
OOP IN VERIFICATION
module test(pAddr, Pwrite, Psel, PWData, Penable, task write(reg[15:0] addr, reg[15:0] data);
Rst, clk); @(posedge clk)
initial begin Paddr <= addr;
PWData <= data;
reset(); PWrite <= 1’b1;
write(16’h50, 32’h50); Psel <= 1’b1;
if([Link][16’h50] == 32’h50)
$display(“Success”); @(posedge clk) Penable = 1’b1;
else @(posedge clk) Penable = 1’b0;
$display(“Error”); endtask
$finish;
end task reset();
endmodule Rst <= 0;
#100 Rst<= 1’b1;
endtask
OOP IN VERIFICATION
OOP IN VERIFICATION
• Layered Testbench layers:
– Signal layer
▪ Contains the design under test and the signals that connect it to the
testbench
– Command Layer
▪ Deals directly with the DUT using pin-level commands
▪ Contain the following components
▪ Driver
▪ Converts transaction stream to pin-level activity
▪ Monitor
▪ Monitors pin-level activity for incorrect behavior
▪ Totally passive: no affect on DUT
OOP IN VERIFICATION
OOP IN VERIFICATION
– Functional Layer
▪ Abstract layer that feeds down command layer with basic commands
▪ Contain the following components
▪ Agent
▪ Receives higher-level transactions breaks them into individual commands or
transactions and sends them to driver and scoreboard
▪ Scoreboard
▪ Predicts the results of the transaction received from the agent
▪ Checker
▪ compares the commands from the monitor with those in the scoreboard
OOP IN VERIFICATION
OOP IN VERIFICATION
– The scenario layer
▪ Drives the functional layer according to the scenario
▪ Contain the following components
▪ Generator
▪ The main component of the scenario layer which drives the functional layer
OOP IN VERIFICATION
OOP IN VERIFICATION
– The test layer
▪ Top level layer used to control the generator(s) of the scenario layer and
measure coverage
▪ Similar to the conductor in an orchestra
▪ Contain the following components
▪ Test
▪ Control the generator(s) of the scenario layer
▪ Measure the progress of all test in he fulfilling of the verification plan
What the heck?
There are too
many layers. I am
just going to stick
to flat test bench
instead
OOP IN VERIFICATION
• Layered testbench may seem
– More complex
– Take more time to develop
• However, they
– let’s take an example
OOP IN VERIFICATION
Adder
OOP IN VERIFICATION
Multiplier
OOP IN VERIFICATION
Any two input
and single
output design
OOP IN VERIFICATION
• Layered Testbench helps to make your task easier by dividing the
code into smaller pieces that can be developed separately and
this improve
– Reusability
– Maintainable
– Configurable
Challenge:
how would you develop these layered testbench components
Easy, develop
each
component in
a sperate
module
OOP IN VERIFICATION
• Modules are
– usually used to model hardware
– communicate using ports
– harder to develop than software
– have synchronization issues
– not reusable
– hard to maintain
Challenge:
how would you develop these layered testbench components
Solution:
Use classes
OOP IN VERIFICATION
• Classes are
– software components
– have many ways to communicate including mailboxes and virtual
interfaces
– Extremely reusable when developed correctly
– easier to develop than hardware
– easier to maintain than module
OOP IN SYSTEMVERILOG
OOP IN SYSTEMVERILOG
• The four pillars of OOP are:
– Inheritance
– Encapsulation
– Polymorphism
– Abstraction
OOP IN SYSTEMVERILOG:
INHERITANCE
• Inheritance is the OOP ability that allows classes to be
derived from other classes.
• The parent class is called a superclass
• The derivatives classes are called subclasses.
OOP IN SYSTEMVERILOG:
INHERITANCE
• Inherit or extend properties and methods
from other classes
– Original class is the base or super class
– Extended class is the derived or sub-class
• Allows customization without breaking or
rewriting known-good functionality in the
base class
– instead of copying and modifying we “extend”
classes by inheritance
OOP IN SYSTEMVERILOG:
INHERITANCE
OOP IN SYSTEMVERILOG:
INHERITANCE
• ErrorPkt inherits all of Packet, that is to say ErrorPkt "is a" Packet
plus ErrorPkt may have addional methods and properties
Challenge:
What if you want to redefine a method in a subclass that was already
defined in its parent class?
Solution:
Method Override
OOP IN SYSTEMVERILOG:
INHERITANCE
• To override a method means that given a base class with a
method, we can define a subclass which extends from that base
class and then provide a new definition for the given method
OOP IN SYSTEMVERILOG:
INHERITANCE
class A ; class B extends A;
integer j = 5; integer i = 1;
task print(); // Override the parent
$display("j is %0d",j); task print();
endtask $display("i is %0d",i);
endclass $display("j is %0d",j);
endtask
endclass
Challenge:
What if you want to extend a super class method in its subclass? or what if you want
to call a super class method that was later overridden in a subclass?
Solution:
super
OOP IN SYSTEMVERILOG:
INHERITANCE
• The super keyword is used from within a derived class to refer to
members of the parent class. It is necessary to use super to access
members of a parent class when those members are overridden by
the derived class.
• The member can be a member declared a level up or be inherited
by the class one level up. There is no way to reach higher (for
example, [Link] is not allowed).
OOP IN SYSTEMVERILOG:
INHERITANCE
OOP IN SYSTEMVERILOG:
INHERITANCE
• Class constructor may be overridden too
class A ; class B extends A;
integer i;
integer;
// Override the parent
function new ();
function new ();
j=5 ; i=5;
endfunction endfunction
endclass endclass
OOP IN SYSTEMVERILOG:
INHERITANCE
• When using the super within new, [Link] shall be the first
statement executed in the constructor.
– This is because the superclass must be initialized before the current
class and if the user code doesn’t provide an initialization, the compiler
shall insert a call to [Link] automatically.
Challenge:
What if the super class constructor had any arguments?
Solution:
[Link]
OOP IN SYSTEMVERILOG:
INHERITANCE
• Class constructor may be overridden too
class A ; class B extends A;
integer i;
integer;
// Override the parent
function new (int function new ();
addr); [Link](100);
j=addr ; i=5;
endfunction endfunction
endclass endclass
OOP IN SYSTEMVERILOG:
INHERITANCE
Wait
So if ErrorPkt is a
pkt, would that
mean that I can
assign them to
each other?
OOP IN SYSTEMVERILOG:
INHERITANCE ASSIGNMENTS
module try;
class Trans;
int i; # i= 100
function void Display_i();
# i= 100
$display("i=%d",i);
endfunction : Display_i
endclass
class BadTrans extends Trans ;
int j;
function void Display_j();
$display("j=%d",j);
endfunction : Display_j
endclass
BadTrans m_BadTrans = new();
Trans m_trans;
initial begin
m_BadTrans.i=100;
m_BadTrans.Display_i();
m_trans = m_BadTrans;
m_trans.Display_i();
end
endmodule : try
OOP IN SYSTEMVERILOG:
INHERITANCE ASSIGNMENTS
• You can assign an extended handle to a base handle, and no
special code is needed
• When a class is extended, all the base class variables and
methods are included, so BadTrans is in the extended object. The
assignment to Trans is permitted, as any reference using the base
handle trans is valid, such as m_trans.i or m_trans.Display_i()
• What about the other way around?
OOP IN SYSTEMVERILOG:
INHERITANCE ASSIGNMENTS
module try;
class Trans;
int i; # ** Error: [Link](20): types are
function void Display_i();
not assignment compatible
$display("i=%d",i);
endfunction : Display_i
endclass Compile time error
class BadTrans extends Trans ;
int j;
function void Display_j();
$display("j=%d",j);
endfunction : Display_j
endclass
BadTrans m_BadTrans ;
Trans m_trans=new();
initial begin
m_trans.i=100;
m_trans.Display_i();
m_BadTrans = m_trans;
m_BadTrans.Display_i();
end
endmodule : try
OOP IN SYSTEMVERILOG:
INHERITANCE ASSIGNMENTS
• Copying a handle to a base object into an extended handle doesn’t
work
• Base object is missing properties that only exist in the extended
class, such as j or Display_j().
• The SystemVerilog compiler does a static check of the handle
types and will not compile the assignment line.
• Remember that you can always check it types are compatible
using dynamic cast
– $cast(destination_expression, source_expression)
▪ this will try to assign the source to destination and if it fails, it will return zero
OOP IN SYSTEMVERILOG:
INHERITANCE ASSIGNMENTS
module try;
class Trans;
int i;
function void Display_i();
# i= 100
$display("i=%d",i); # Error can't assign extended
endfunction : Display_i class handle to base class handle
endclass
class BadTrans extends Trans ;
int j;
function void Display_j();
$display("j=%d",j);
endfunction : Display_j
endclass
BadTrans m_BadTrans ;
Trans m_trans=new();
initial begin
m_trans.i=100;
m_trans.Display_i();
if($cast(m_BadTrans,m_trans))
m_BadTrans.Display_i();
else
$display("Error can't assign extended class handle to base class
handle");
end
endmodule : try
OOP IN SYSTEMVERILOG:
INHERITANCE ASSIGNMENTS
module try;
class Trans;
function void PrintCLassName();
Trans
$display("Trans");
endfunction : PrintCLassName
function void ShowDetails();
PrintCLassName();
endfunction : ShowDetails
endclass
class BadTrans extends Trans ;
function void PrintCLassName();
$display("BadTrans");
endfunction : PrintCLassName
which • The trans class doesn’t know
endclass
ShowDetails anything about the
BadTrans t1 = new(); ShowDetails in the child class
will be called?
initial begin
[Link]();
end
endmodule : try
Challenge:
How can we have the base class method call the overridden method in the derived
class instead?
Solution:
Virtual methods
OOP IN SYSTEMVERILOG:
INHERITANCE ASSIGNMENTS
module try;
class Trans;
virtual function void PrintCLassName();
BadTrans
$display("Trans");
endfunction : PrintCLassName
function void ShowDetails();
PrintCLassName();
endfunction : ShowDetails
endclass
class BadTrans extends Trans ;
function void PrintCLassName();
$display("BadTrans");
endfunction : PrintCLassName
which
endclass
ShowDetails
BadTrans t1 = new();
will be called?
initial begin
[Link]();
end
endmodule : try
OOP IN SYSTEMVERILOG:
INHERITANCE ASSIGNMENTS
• To decide which virtual method to call, SystemVerilog uses the
object’s type, not the handle’s type.
• In the last statement, t1 points to an extended object (BadTrans)
and so BadTrans::PrintCLassName is called
• Static methods cannot be virtual
OOP IN SYSTEMVERILOG:
ENCAPSULATION
• Encapsulation is all about wrapping variables and methods in
one single unit.
OOP IN SYSTEMVERILOG:
ABSTRACTION
• Refers to showing only the essential features of the
application and hiding the details
• Abstraction = Encapsulation + Data hiding
• Data Hiding in SystemVerilog
– local
– protected
OOP IN SYSTEMVERILOG:
POLYMORPHISM
• Polymorphism comes from the Greek language, and means “many
forms”
• Polymorphism allows subclasses of a class to define their own
unique behaviors and yet share some of the same functionality of
the parent class
OOP IN SYSTEMVERILOG:
POLYMORPHISM
class animal
speak();// method
class cat class dog
speak();// method speak();// method
OOP IN SYSTEMVERILOG:
POLYMORPHISM
• Polymorphism is dynamic method lookup
– Polymorphism allows the use of a variable in the superclass to hold
subclass objects, and to reference the methods of those subclasses
directly from the superclass variable.
– Polymorphism is the ability to have the same code act differently based
on the type of an object its working with.
• Remember when using virtual
– To decide which virtual method to call, SystemVerilog uses the object’s
type, not the handle’s type
OOP IN SYSTEMVERILOG:
POLYMORPHISM
class Animal;
module try;
virtual task Speak();
$display("Error"); Cat m_cat = new();
endtask Dog m_dog = new();
endclass
Duck m_duck = new();
class Cat extends Animal ; Animal m_animal;
task Speak(); // over-ridden method
initial begin
$displayh("Meow");
endtask m_animal = m_cat;
endclass m_animal.Speak();
class Dog extends Animal ;
task Speak(); // over-ridden method m_animal = m_dog;
$displayo("Woof");
m_animal.Speak();
endtask
endclass
// m_animal = m_duck;
class Duck extends Animal ;
task Speak(); // over-ridden method
m_animal.Speak();
$displayo("Quack"); end
endtask
endmodule
endclass
OOP IN SYSTEMVERILOG:
POLYMORPHISM
OOP IN SYSTEMVERILOG:
POLYMORPHISM
class Transaction; class BadTr extends Transaction;
bit bad_csm = 1’b1;
bit [31:0] src, dst,
function void calc_csm()
data[8];
super.calc_csm();
bit [31:0] csm; csm = ~csm;
function void calc_csm(); endfunction
csm = src ^ dst ^ endclass
[Link]; //driver class
endfunction Transaction trans;
task drive ();
endclass in_chan.get(trans);
trans.calc_csm();
// drive DUT
endtask
OOP IN SYSTEMVERILOG:
POLYMORPHISM
class Transaction; class BadTr extends Transaction;
bit bad_csm = 1’b1;
bit [31:0] src, dst,
function void calc_csm()
data[8];
super.calc_csm();
bit [31:0] csm; csm = ~csm;
virtual function void endfunction
calc_csm(); endclass
csm = src ^ dst ^ //driver class
[Link]; Transaction trans;
task drive ();
endfunction
in_chan.get(trans);
endclass trans.calc_csm();
// drive DUT
endtask
OOP IN SYSTEMVERILOG:
POLYMORPHISM
• Constructors are Never Virtual? Why??
– SystemVerilog checks the type of the object to
decide if it should call the method in the base class or the extended.
– When you call it, there is no object whose
type can be checked. The object only exists after the constructor call
starts
OOP IN SYSTEMVERILOG: MORE ON
VIRTUAL
• A class itself can be virtual
– Also called abstract class or virtual class
– can be extended,
– can’t be instantiated directly.
– Useful for creating sharable base class between different projects or
features (say a test base)
OOP IN SYSTEMVERILOG: MORE ON
VIRTUAL
virtual class BasePacket;
virtual function integer send(bit[31:0] data);
endfunction
endclass
class EtherPacket extends BasePacket;
function integer send(bit[31:0] data);
// body of the function
...
endfunction
endclass
OOP IN SYSTEMVERILOG: MORE ON
VIRTUAL
• EtherPacket is now a class that can be instantiated.
• if an abstract class has any virtual methods, all of the methods
must be overridden (and provided with a method body) for the
subclass to be instantiated.
• If any virtual methods have no implementation, the subclass
needs to be abstract.
• An abstract class can contain methods for which there is only a
prototype and no implementation (i.e., an incomplete class).
• An abstract class cannot be instantiated, it can only be derived.
OOP IN SYSTEMVERILOG: MORE ON
VIRTUAL
• Virtual pure function is a function template in your base class that
MUST BE overridden in your derived class with new code.
– Can be defined in abstract classes only
– force the user of your code to complete or provide addional data that is
needed for operation
– must be overridden in subclass or the compiler will generate a compile
time error
FINAL REMARKS
COMMON INTERVIEW QUESTION
• Method overloading VS method overriding
• What is polymorphism? write an example.
• What is super in SystemVerilog?
• What is the use of virtual in SystemVerilog?
ASSIGNMENTS
• Reading assignment: Study chapter eight from SystemVerilog for
Verification book (47 pages)
• Reading assignment: overloading vs overriding
– [Link]
ava-with-examples/
– [Link]
overloading
REFERENCES
• Main textbook: SystemVerilog for Verification by Chris
Spear
• Writing Testbenches using System Verilog
• SystemVerilog Language Reference Manual
THANK YOU