Have you ever been asked to explain polymorphism as a Design Verification engineer? This is a common interview question for Design Verification roles and I also used to ask it frequently during interviews. Most engineers explain polymorphism with examples like a parent class (shape) defining a method to calculate the area, while child classes (circle, rectangle, triangle) override it for specific implementations. While these examples are correct they don’t align well with our domain.
Testbench Architecture
So how should you explain polymorphism as a Design Verification engineer? I believe explaining it using something more relevant to RTL design like the payload of a bus and its parity signal, would be more effective. As an example, consider a parent class as a base transaction object randomizing a payload and generating its parity bit. A child class could then be a transaction class generating parity errors. This approach not only explains polymorphism but also: • Introduces modern Testbench Architecture with transaction objects and sequences • Explores randomize() and post_randomize() methods in SystemVerilog • Sets the interview tone around design verification principles What do you think about it?