Trace calls from handle and object types, distinguish overriding from hiding, and use abstract classes and checked casts safely.
Values, containers, and ownership.
The language bench / dispatch
Which method answers the call?
class Animal;
virtualfunction string speak(); return"Animal"; endfunction
endclass
class Dog extends Animal;
function string speak(); return"Dog"; endfunction
endclass
Animal a; Dog d = new; a = d;
a.speak();
Question directory
Questions for Dispatch + abstraction
Open an authored answer, then use the adjacent object diagram or code example to verify the mechanism.
SystemVerilog inheritance and dispatchSeparate handle type from object type.
Trace virtual calls, non-virtual hiding, super calls, static method resolution, and the constructor-time dispatch trap without guessing from the variable name.
Concept model
The virtual keyword changes the lookup path
declared handle typeAnimal awhat the compiler sees
follow object type→
dynamic object typeDogwhat was allocated
resolved implementationDog::speak()woof
Runtime dispatchThe base declaration marked the method virtual, so the object's dynamic type selects the implementation.
Virtual calls follow the dynamic object type. Non-virtual and static calls are bound from the declared type or class scope, even when the handle refers to a derived object.
Strong answer
When the base declaration is virtual, a call through any compatible handle dispatches from the dynamic type of the object. A base handle referring to a Dog therefore invokes Dog::speak().
Reason it through
The handle's declared type controls which members are legal to name at compile time.
The object's dynamic type controls which virtual override executes at runtime.
Once a method is virtual in a base class, matching overrides remain virtual down the hierarchy.
Upcast, then dispatch dynamicallysystemverilog
class Animal;
virtualfunctionstring speak();
return"noise";
endfunctionendclassclass Dog extends Animal;
functionstring speak();
return"woof";
endfunctionendclass
Dog dog = new;
Animal animal = dog;
$display("%s", animal.speak()); // woof
Strong answer
A derived method overrides a matching virtual base method and participates in runtime dispatch. A same-named method whose base declaration is non-virtual only hides that name; calls remain bound by the handle's declared type.
Reason it through
Derived d = new; d.who() can call Derived::who even when the method is non-virtual because d is declared Derived.
Base b = d; b.who() calls Base::who when the base declaration is non-virtual.
Make the base method virtual and preserve the signature when polymorphic substitution is required.
Override and hiding behavior
Base declaration
Call through Base handle
Call through Derived handle
Base declarationvirtual
Call through Base handleDerived override
Call through Derived handleDerived override
Base declarationnon-virtual
Call through Base handleBase method
Call through Derived handleDerived hidden method
Strong answer
super.method() invokes the immediate superclass implementation directly from the derived method. It is useful for extending base behavior rather than replacing it completely.
Reason it through
In C::vf, super.vf() names B::vf when C extends B.
If B::vf also calls super.vf(), that nested call reaches A::vf.
The call is selected lexically from the class hierarchy, not by searching the runtime object again.
Extend the immediate base implementationsystemverilog
class A;
virtualfunctionstring name(); return"A"; endfunctionendclassclass B extends A;
functionstring name();
return {"B(", super.name(), ")"};
endfunctionendclassclass C extends B;
functionstring name();
return {"C(", super.name(), ")"};
endfunctionendclass// C object prints C(B(A))
Strong answer
Static members belong to a class type, not an object. A derived same-named static member shadows a separate base member, and a call is resolved from class scope or the handle's declared type rather than the dynamic object type.
Reason it through
Base::inc() updates Base::cnt and Der::inc() updates Der::cnt.
A Base handle referring to a Der object still resolves a static call as Base.
In the deck's sequence, Base::get() is 3, Der::get() is 120, and hb.get() resolves to the base value 3.
Track two independent static counterssystemverilog
class Base;
staticint cnt = 0;
staticfunctionvoid inc(); cnt++; endfunctionstaticfunctionint get(); return cnt; endfunctionendclassclass Der extends Base;
staticint cnt = 100;
staticfunctionvoid inc(); cnt += 10; endfunctionstaticfunctionint get(); return cnt; endfunctionendclass
Base b = new;
Der d = new;
Base hb = d;
Base::inc(); Der::inc();
b.inc(); d.inc(); hb.inc();
// Base::get() = 3, Der::get() = 120, hb.get() = 3
Strong answer
Virtual dispatch can enter the derived override while the base constructor is still running, before the derived constructor has initialized its fields. The override observes default or partially initialized derived state.
Reason it through
If BaseB.new calls build() and the object is DerB, DerB::build can run before DerB.new assigns ready = 1.
The printed ready value is therefore 0, the default for int, rather than the intended initialized value.
Keep constructors non-polymorphic and call a separate build or configure phase only after construction completes.
Move virtual work after constructionsystemverilog
class DerB extends BaseB;
int ready;
functionnew();
super.new();
ready = 1;
endfunctionfunctionvoid build();
$display("ready=%0d", ready);
endfunctionendclass
DerB d = new;
d.build(); // safe: construction is complete
Strong answer
For every call, write down the handle's declared type, the object's dynamic type, and whether the base declaration is virtual. Virtual calls follow the dynamic type; non-virtual calls follow the handle type; super calls follow the immediate base implementation.
Reason it through
An A handle referring to C calls C::vf when vf is virtual but A::nf when nf is non-virtual.
After a successful $cast to B, the B handle still refers to the same C object; a non-virtual nf call now binds to B::nf.
A C handle binds the same non-virtual call to C::nf, while every compatible handle still dispatches virtual vf to C.
Polymorphism trace checklist
Call kind
Lookup source
Object copied?
Call kindvirtual instance method
Lookup sourceDynamic object type
Object copied?No
Call kindnon-virtual instance method
Lookup sourceDeclared handle type
Object copied?No
Call kindstatic method
Lookup sourceClass scope or handle type
Object copied?No
Call kindsuper.method()
Lookup sourceImmediate superclass implementation
Object copied?No
SystemVerilog abstract types and castingProgram to a contract you can check.
Use virtual classes and pure virtual methods to define incomplete base types, then move through the hierarchy with safe upcasts and checked downcasts.
Concept model
Abstract bases define the contract boundary
Abstract contractDeclare the promise once
cannot instantiatevirtual class Shapepure virtual function area()
Handle conversionUpcast freely; check the way down
Rect handle→Shape handleupcast · always safe
Shape handle→Rect handle$cast() · runtime check
A concrete child must satisfy every inherited pure virtual contract. Upcasting preserves the object behind a base handle; $cast() verifies a downcast at runtime.
Strong answer
A virtual class is an abstract class type that cannot be instantiated directly. A virtual method is an instance method that supports runtime overriding; a concrete class may contain virtual methods and still be instantiable.
Reason it through
A virtual class may contain implemented properties and ordinary or virtual methods.
Declaring a class virtual says the type itself is incomplete, even when it has no pure method.
Declaring a method virtual changes dispatch for that method but does not make the class abstract.
Virtual class and virtual method
Construct
Main effect
Can enclosing class be instantiated?
Constructvirtual class
Main effectType is abstract
Can enclosing class be instantiated?No
Constructvirtual method
Main effectCall dispatches dynamically
Can enclosing class be instantiated?Yes, if class is concrete
Constructpure virtual method
Main effectDerived concrete type must implement it
Can enclosing class be instantiated?Only legal in an abstract class
Strong answer
A pure virtual method declares a signature without an implementation. Every non-virtual derived class must provide a matching implementation or the derived class must remain virtual.
Reason it through
The containing class must be declared virtual.
A virtual intermediate class may defer the implementation to a later concrete child.
Pure methods are useful for interface-style contracts such as format(), send_pkt(), or area().
Declare and satisfy a contractsystemverilog
virtualclass Shape;
purevirtualfunctionint area();
endclassclass Rect extends Shape;
int w, h;
functionnew(int w = 1, int h = 1);
this.w = w;
this.h = h;
endfunctionfunctionint area();
return w * h;
endfunctionendclass
Strong answer
Every derived object satisfies its base type, so assigning a derived handle to a base handle is safe. A base handle may refer to many possible dynamic types, so $cast() must verify a downcast at runtime.
Reason it through
An upcast changes only the handle view; the same object remains allocated.
$cast(destination, source) returns 1 and assigns the handle when the dynamic object is compatible.
A failed cast returns 0 and should take an explicit error or alternate path.
Check a downcast at runtimesystemverilog
Rect original = new(3, 4);
Shape base = original; // safe upcast
Rect recovered;
if ($cast(recovered, base))
$display("area=%0d", recovered.area());
else
$display("incompatible dynamic type");
Strong answer
The derived method must preserve the base method's name and compatible prototype, including return type and formal argument contract. It then remains virtual even if the keyword is omitted in the derived declaration.
Reason it through
Changing the argument list does not create a useful overload; SystemVerilog method overloading is not supported.
Changing only the implementation is the normal override.
Use a differently named helper when the derived class needs extra inputs beyond the base contract.
Strong answer
Yes. A virtual class cannot be constructed directly, but its handle may refer to any compatible concrete derived object and invoke the abstract contract polymorphically.
Reason it through
Shape s; is legal because it declares only a handle.
Rect r = new(3, 4); s = r; is a safe upcast.
Calling s.area() dispatches to Rect::area and returns 12.
