An insatiable hunger for smarter, sleeker and power efficient electronics has put tremendous pressure on research and implementation of ASICs that fit the bill. While ASIC design is continuously under a sea change, ASIC Verification cannot shy away from change either. In order to verify the increasingly complex and large designs, the testbench architecture made a significant shift from the procedural to the more refined layered approach. This was possible with the introduction of Hardware Verification Languages (HVLs) and the gamut of features they offer that make the modern day verification keep pace with the designs. Many HVLs have come into the picture, but SystemVerilog is the most popular and widely accepted one. SystemVerilog also is known as Super Verilog borrows its concepts from Hardware Description Languages (HDLs) such as Verilog and VHDL as well OOPS (Object Oriented Programming Concepts).
Besides offering ‘hardware’ modelling features from the HDLs, SystemVerilog encompasses key OOP concepts such as Abstraction, Encapsulation, Inheritance and Polymorphism. The concept of ‘Abstraction’ makes it possible for DV engineers to plug and play key SV features in their code without bothering about the nitty gritty of their internal implementation. For example, a ‘semaphore’ and ‘mailbox’ can be plugged in to avoid the complexity of writing code that handles interprocess synchronization and communication. ‘Encapsulation’ makes it possible to ‘objectify’ testbench components, each component such as driver, monitor or transaction can be defined as an object that contains properties and methods that act on those properties. By the concept of ‘Inheritance’, it becomes possible for the derived class objects to ‘inherit’ their parent class properties and methods, thus setting a ‘base’ for further modifications if need be. This eliminates reinventing of the wheel or in other words rewriting a whole bunch of a code in the event that the testbench needs upgrades/edits. ‘Polymorphism’ one of the most useful concepts incorporated into SystemVerilog clubbed with ‘Inheritance’ makes it possible to have a ‘single’ object assume ‘multiple’ forms. Additionally and the most interesting part is that regardless of the number of forms/derivatives/extensions of this base class, the interface for each of those remains the same.
While there are plenty of concepts and features that SystemVerilog entails and offers, we shall be talking about the ‘Polymorphism’ concept at length. Let us understand more about polymorphism, how it works and how does it contribute to the process of building a smart testbench.
What Is Polymorphism?
Polymorphism is a key OOPS (Object Oriented Programming System) imbibed by SystemVerilog. ‘Polymorphism’ is a term derived from two Greek words, ‘poly’ meaning many and ‘morph’ means forms. Thus, ‘Polymorphism’ is a concept which when applied helps a ‘single’ object assume ‘multiple’ forms. In the programming context, polymorphism implies the ‘reuse’ of a single piece of code, multiple times. The greatest advantage this concept renders to SystemVerilog is that a base class object can have multiple derivatives with different attributes (Ethernet packet, TCP/IP packet, UDP packet, etc.), yet the interface to all those derivatives can still be the base class. Since the ‘user’ interface despite the multiple modifications remains constant, top-level testbench code need not be modified. Additionally, inheritance and polymorphism work hand in glove, hence the need to modify a lot of code to reflect changes or an entirely different protocol are minimal. Thus ‘Polymorphism’ plays a significant part in catalysing verification as well as promoting ‘code reusability’.
Let us take a simple example of a ‘car’ and consider it to be the ‘base class’. A car can be a sedan, a hatchback or an SUV. It can also have distinct properties such as colour, fuel-efficiency, braking, locking and gear system, and so on. Yet, all of these are referred to as ‘car’. Hence, regardless of the number of ‘variations,’the base class may have, each of these variations can still be ‘categorized’ or referred by the ‘Base Class’. Similarly, a base class can be extended to have multiple derivatives that possess characteristics that are different from each other, yet can be accessed via the base class handle. The diagram above depicts this.
Polymorphism In SystemVerilog
Polymorphism and Inheritance work in synchronism to make SystemVerilog based test benches easier to build, maintain, modify and reuse. Let us take a look at how this happens. A base class object that contains virtual methods can be overridden and moulded into multiple forms bearing different or enhanced properties as well as behaviour. Let us take an example of a Network Switch DUT that can handle/process Ethernet, UDP (User Datagram Protocol) and TCP/IP (Transmission Control Protocol/ Internet Protocol). Since the network can receive these protocol packets in a random order, a scenario wherein a TCP/IP packet can follow an Ethernet packet or even a UDP packet is real. In order to model this, an array of different packets must be defined for the DUT to handle/process/drive.
In order to construct this kind of an array, an array bearing the base class type must be formed, else multiple arrays of each derived class object type must be defined. Additional logic would be needed to feed the packets from each of those ‘multiple’ arrays to create a real-life scenario wherein UDP, TCP/IP and Ethernet packet can be injected in any order. This would imply the addition of complex logic. Thus, we would ideally need an array of ‘Base_Packet’ type rather than maintaining multiple arrays of different ‘Packet’ types. For the array to be defined of the base class ‘Base_Packet’ type, it is needed to assign the derived class object handle to the base class handle each time the derived class object needs to be driven. It becomes impossible to assign the derived class object handle to the parent class. For e.g., If we want a stream of TCP/IP, Ethernet and UDP packets in this sequence, we cannot achieve this without defining multiple pointers and typecasting. The following example illustrates the complexity needed to assign a single derived class object handle to the parent class.
By defining the methods in the ‘Base_Packet’ definition as virtual, this base class becomes eligible for ‘polymorphism’. The derivatives of this class namely ‘Ethernet_Packet’, ‘TCP/IP_Packet’ and ‘UDP_Packet’ can inherit its features and functions as well as enhance them by the concept of ‘Inheritance’. ‘Polymorphism’ comes into play when we create a scenario when each of these packets needs to be driven in order or in random sequences to mimic a real-life scenario where the network switch would receive network traffic of all packet types. A ‘Base_Packet’ handle can contain an ‘Ethernet_Packet’, ‘TCP/IP_Packet’ or ‘UDP_Packet’ object. Thus an array of the ‘Base_Packet’ type can be defined and that can contain packets of different types because of the concept polymorphism. There is no need to handle multiple pointers, typecasting or adding other complex logic to drive ‘different’ data objects from a single thread. In case, an additional packet type needs to be added to reflect an enhancement in the DUT, the top level does not need to be changed as the ‘interface’ which is the ‘Base_Packet’ handle, in this case, remains ‘constant’. The diagram below depicts this.
Summary
HVLs (Hardware Verification Languages) revolutionized the way verification was being done. SystemVerilog has gained precedence over other HVLs and is now widely accepted and adopted. SystemVerilog has been built by borrowing concepts from Verilog, VHDL and OOPs and it comes loaded with constructs/features that greatly ease the verification process. Modern day designs are advancing at a jet speed and verification must catch up. To cope up with the speed of changing technology, DV engineers like the design engineers must build test benches that are faster to build, easier to modify and maintain, reusable or in other words plug and play.
By inculcating key OOPS concepts such as Data Abstraction, Encapsulation, Inheritance and Polymorphism, System Verilog based test benches have managed to address almost all the modern day verification challenges. By the concept of ‘polymorphism’ combined with ‘inheritance’, a single piece of code can assume multiple forms. A single base class object can be extended to have multiple derivatives which can exhibit different features and functions from this base class. The key lies in being able to assign the derived class object handle to the base class handle by simply declaring the methods in the base class as ‘virtual’. Thus, we can keep the base class as the ‘constant’ interface regardless of the number of derivatives it has. If there are modifications/enhancements to be done in order to fit protocol changes, all that needs to be done is defining the derived class that reflects those enhancements and assigning a pointer to it to the base class handle. The top-level testbench code remains blissfully unaware of the changes that happened to the protocol or the design in general. Thus, polymorphism promotes code ‘reusability’, hence cutting down the time and effort invested in testbench development.