Interrupt handling is a well-known feature of any SoC which usually comprises of CPU, Bus Fabric, several Controllers, Sub-Systems & many IP blocks as part of it. In some way or other Interrupts are used to act as the sideband signals of the Design/IP Blocks & most of the time it’s not the part of the main…
How to connect the DUT to the UVM Testbench?? In our traditional directed Testbench environments, all the components are “static” in nature & information (data/control) is also exchanged in the form of signals/wire/nets at all levels in the DUT as well as in TestBench. But this is not the case in the latest “Constrained Random Verification Methodology” like…
Introduction As technologies advance, we see increasingly complex SoCs in the market, SoCs that have various wireless modules, and processors that use new bus architectures to communicate with them. They can also have various interfaces like I2C, PCM, I2S, AHB, etc. Yet, these SoC components will share a single clock control unit. This module generates…
Today, let’s delve into UVM RAL: What it is, its importance, and the structure it entails. The discussion will cover the definition of RAL, the reasons for its necessity, and an overview of the UVM RAL framework design. It is essential to understand that our Device Under Test (DUT), whether an SoC or Subsystem, contains…
In the intricate world of ASIC Verification, the SOC Verification Flow is a cornerstone process that necessitates both expertise and experience. Many people may not fully understand what sets a system-on-chip (SoC) apart from other semiconductor devices. Within the realm of electronic design automation (EDA), the term “SoC” is often used without a clear definition or explanation…
Scoreboard The basic function of the scoreboard is to check the correctness of the output data of the design under test. The scoreboard you create should derive from uvm_scoreboard; however, there is no current functionality of the uvm_scoreboard. You may be wondering why it’s important to mention if it doesn’t have any functionality at the…
AGENTS As mentioned, an agent is a container that instantiates the driver, monitor, and sequencer. Agents can be either active or passive. In active mode, all three components are created, while in passive mode only the monitor is created. Since we have already built the necessary components, creating the agent is simply a matter of…
SEQUENCER The job of the sequencer is to control the flow of sequences to the driver. The fact that you can write six lines of code yet have a powerful implementation is the beauty of UVM. Having the sequencer mechanism prepared for you in the library allows you to build the testbench faster and more…
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…
A 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,…