Polymorphism in SystemVerilog

The word "polymorphism" comes from Greek and means "many forms". In programming, it means that a single method or function can behave differently depending on which object is calling it.

Why is Polymorphism Important?

In verification, polymorphism helps you:

• Write reusable code - Same testbench code can test different DUT configurations
• Extend functionality easily - Add new transaction types without changing existing code
• Create flexible test environments - Swap components at runtime
• Build UVM testbenches - UVM heavily relies on polymorphism for its architecture

The secret to polymorphism in SystemVerilog is the virtual keyword. When you declare a method as virtual, you're telling SystemVerilog: "The actual method to call should be determined at runtime, based on the actual object type."

Without Virtual (Static Binding)

Without virtual, the method that gets called is determined by the variable type at compile time. This is called static binding.

class Animal;
    function void speak();
        $display("Some generic animal sound");
    endfunction
endclass

class Dog extends Animal;
    function void speak();
        $display("Woof! Woof!");
    endfunction
endclass

// In testbench:
Animal a;
Dog d = new();
a = d;        // Parent handle pointing to child object
a.speak();    // Prints: "Some generic animal sound" - NOT what we want!

With Virtual (Dynamic Binding)

With virtual, the method that gets called depends on the actual object type at runtime. This is called dynamic binding or late binding.

class Animal;
    virtual function void speak();
        $display("Some generic animal sound");
    endfunction
endclass

class Dog extends Animal;
    virtual function void speak();  // 'virtual' optional in child, but good practice
        $display("Woof! Woof!");
    endfunction
endclass

// In testbench:
Animal a;
Dog d = new();
a = d;        // Parent handle pointing to child object
a.speak();    // Prints: "Woof! Woof!" - Correct!

Let's see a real-world verification example. Imagine you have different types of transactions: read, write, and burst transactions. They all need to be printed and compared, but each has its own format.

class Transaction;
    rand bit [31:0] addr;
    rand bit [31:0] data;
    
    // Virtual methods - child classes will override these
    virtual function void display();
        $display("Transaction: addr=0x%h, data=0x%h", addr, data);
    endfunction
    
    virtual function bit compare(Transaction t);
        return (this.addr == t.addr) && (this.data == t.data);
    endfunction
endclass

class ReadTransaction extends Transaction;
    rand bit [3:0] burst_len;
    
    virtual function void display();
        $display("READ Transaction: addr=0x%h, burst=%0d", addr, burst_len);
    endfunction
endclass

class WriteTransaction extends Transaction;
    rand bit [3:0] strobe;
    
    virtual function void display();
        $display("WRITE Transaction: addr=0x%h, data=0x%h, strobe=0x%h", 
                 addr, data, strobe);
    endfunction
endclass

// Array of base class handles
Transaction trans_queue[$];

// Add different transaction types to the same queue
ReadTransaction  rd = new();
WriteTransaction wr = new();

rd.randomize();
wr.randomize();

trans_queue.push_back(rd);
trans_queue.push_back(wr);

// Print all transactions - each calls its own display()!
foreach(trans_queue[i]) begin
    trans_queue[i].display();  // Correct method called automatically
end

UVM uses polymorphism everywhere. The most common example is the uvm_sequence_item class. All your transactions extend from it, and UVM components can work with any transaction type through the base class handle.

• Sequences - One sequencer can handle different transaction types
• Drivers - Virtual methods let you customize driving behavior
• Monitors - Override methods to capture DUT-specific protocols
• Scoreboards - Compare transactions using polymorphic compare methods

• Polymorphism = "many forms" - same method, different behavior based on object type
• Use the virtual keyword to enable polymorphism
• Without virtual → static binding (method decided at compile time)
• With virtual → dynamic binding (method decided at runtime)
• Essential for UVM and flexible testbench design

Now that you understand polymorphism, you're ready to explore more advanced SystemVerilog concepts. We recommend:

• Data Types - Understand the building blocks of SV
• Randomization - Learn how to generate random test data
• UVM Tutorials - See polymorphism in real testbenches