Polymorphism in SystemVerilog

Polymorphism is one the most important OOP features used by the modern SystemVerilog test benches. This article explores a basic use case for this feature. Assume a testbench needs to monitor a number of DUT interfaces. Those monitors need to be able to reset their internal queues and some state variables whenever reset event happens during the simulation. In addition to resetting queues and variables, they all have one common reset requirement. Here's the code that reflects those assumptions: class mon_a; ... function common(); ... endfunction : common function mon_a_specific(); ... endfunction :  mon_a_specific function reset(); $write("Reset A in progress...\n"); common(); mon_a_specific(); ... endfunction : reset endclass : mon_a class mon_b; ... function common(); ... endfunction : common function mon_b_specific(); ... endfunction :  mon_b_specific function reset(); $write("Reset B in progress...\n"); common(); mon_b_specific(

Interface class in SystemVerilog. What is it good for?

SystemVerilog is an object oriented language. Unfortunately, not all the features inherent in such a language are available. Multiple inheritance is one of them. The new SystemVerilog standard IEEE Std 1800-2012 (SV12) introduces a new class type called "interface class" which can be extended from two or more other interface classes. Unfortunately, the multiple inheritance starts and ends with this type of the class, and due to strict limitations of what can be done with it, the new class type won't solve a problem described below. Moreover, we can't really talk about inheritance when we talk about Interface class. With continuous migration to standard verification methodologies, such as VMM, OVM, and UVM, the lack of ability to inherit from multiple classes causes a lot of grief to the testbench developers. Every SystemVerilog based verification methodology offers a library full of methodology specific base classes. It's essential to extend from those clas