UVM phases are virtual methods defined within the `uvm_component` class. This class can be extended to create custom components such as scoreboards, monitors, and drivers. When extending this class, only the necessary phases are implemented, it is not mandatory to implement all of them.
The `UVM_config_db` is a global database that stores key-value pairs, similar to Python dictionaries. The values can be of various types, such as integers or objects and so on. Keys consist of a hierarchical instance path and a field name: the path defines the scope where the value is visible, and the field name identifies the specific data entry.
The UVM Factory is a software design pattern employed in UVM. It operates as a singleton, meaning it maintains a single class instance. This pattern enables the overriding of objects and UVM components. In essence, it allows the creation and replacement of these elements without requiring modifications to the testbench.
In previous blogs, we have explained the fundamentals of DPI and how to connect Wireshark to a testbench to obtain real-time visualization of stimuli. In this blog, we will detail a use case (real-life scenario) where DPI will be used with Python for stimulus generation, and Wireshark will be used for traffic visualization.
Integrating Wireshark with UVM enables real-time packet capture and analysis during network simulations. By streaming generated packets directly from UVM to Wireshark using a Python-driven pipe, users gain immediate visibility into network traffic, enhancing debugging efficiency and flexibility.
DPI (Direct Programming Interface) in SystemVerilog enables seamless integration with C, Python, MATLAB, and more, enhancing UVM testbenches for advanced verification. Learn how import and export mechanisms work, enabling bidirectional communication with external applications. Discover how to integrate complex algorithms, external libraries, and simulation tools for a more flexible and powerful verification environment.
In modern verification environments, UVM sequences serve as the backbone of stimulus generation. This comprehensive guide is divided into two parts, taking you from fundamental concepts to advanced implementation techniques. This is part two.
In modern verification environments, UVM sequences serve as the backbone of stimulus generation. This comprehensive guide is divided into two parts, taking you from fundamental concepts to advanced implementation techniques.
There are three approaches related to functional verification: black-box, white-box, and gray-box. In this work, a gray-box method is proposed to know the value of internal signals to the DUT. A new class called logic analyzer is created and connected to the DUT using the same approach as the agents. The link between the RTL design and verification components is the top module, where the DUT interface (I/O ports) connects to the virtual interfaces of the agents and, in this case, the logic analyzer.
In this article, we will explore how to apply the SOLID principles within the context of SystemVerilog for verification purposes. Originally introduced by Robert C. Martin in the early 2000s, the SOLID principles are a set of five guidelines aimed at improving the design and maintainability of object-oriented software. The acronym SOLID was subsequently coined by Michael Feathers to represent these key principles. The five principles are:S - Single Responsibility Principle. O - Open/Closed Principle. L - Liskov Substitution Principle. I - Interface Segregation Principle. D - Dependency Inversion Principle
Discover how to effectively use the unique constraint and explore various methods for randomizing sequences in our comprehensive article.
Developing a test where simulation parameters are randomized enables achieving better coverage of the DUT’s state space by simulating different test seeds. This methodology reduces the time required for test creation and maintenance. If a directed test is required, it can be created by adding constraints to the random test.
