Creative ways to solve problems
In earlier post i.e. https://theartofverification.com/uvm-testbench-architecture/ we learned which all components are required to develop UVM Environment/Testbench to verify complex Designs. In this blog post we will verify a small RTL Design by developing complete UVM Environment. Let’s start with the basic RTL Design and understand it’s specifications/working. Here as we can see that in the […]
Continue ReadingA typical UVM testbench contains several components. First, let’s look at a simple UVM testbench diagram. There are several components illustrated within this diagram with the most fundamental one being the agent. An agent is a container that holds all the needed components for a particular protocol. A typical UVM agent might contain a driver, […]
Continue Reading
A verification Engineer is not just to write some test scenarios to verify something it’s way beyond that. A verification engineer’s focus after understanding specifications such as test planning, and strategy need to be applied to verify the complex design, and what needs to be implemented using which methodology. Verification engineers always emphasize why and […]
Continue Reading
If you’re looking to enter the world of ASIC or FPGA verification, then chances are you’ve heard of Universal Verification Methodology (UVM). UVM has become the industry standard for verifying digital designs, and as such, it is a crucial skill set for anyone looking to break into the field. Whether you’re a recent graduate or […]
Continue ReadingSometimes user will face a situation where you need some of the components from environment to demote error message means user want to disable error from a specific component. Of course user don’t want to change every uvm_error message to uvm_info.. It will take care of one of the amazing features from UVM i.e. uvm_report_catcher […]
Continue ReadingToday I’m going to share something which is so common to almost every concept of UVM. In other way, we can say that this concept is the backbone of the UVM Verification Methodology. This is related to the process which deals from the starting of the simulation till end of the simulation. So in this […]
Continue ReadingTo start a UVM Testbench, the run_test() method has to be called from the static part of the Testbench i.e called from an initial block in the top module of the Testbench. Once the run_test() method is called, it constructs the root component of the UVM environment & then triggers the UVM Phasing process. The […]
Continue ReadingMacros: The UVM Library has built-in utility and field automation macros that allow objects to be created by the factory and have access to common functions such as copy( ) or clone( ). To understand how the macros work, let’s build a simple data packet for the DUT. If we were not using the UVM, […]
Continue ReadingAs we know that in Traditional Directed Testbenches, we used to terminate a Test by calling a Verilog System Task i.e. $finish after the required steps like reset, configuration, data transfer and self-checking are completed. But UVM way is different in terms of finishing a Test as UVM is different in almost every aspect of […]
Continue ReadingThe recommended method in UVM for creating components or transaction objects is to use the built-in method::type_id::create() instead of calling the constructor new() directly. The create method internally makes a call to the factory to look up the requested type and then calls the constructor new() to actually create an object. This allows type overriding […]
Continue Reading