UVM–Top Block

In a normal project, the development of the DUT is done separately from the development of the testbench, so there are two components that connects both of them:

• The top block of the testbench
• A virtual interface

The top block will create instances of the DUT and of the testbench and the virtual interface will act as a bridge between them.

The interface is a module that holds all the signals of the DUT. The monitor, the driver and the DUT are all going to be connected to this module.

The code for the interface can be seen in Code 3.1.

interface simpleadder_if;
     logic    sig_clock;
     logic    sig_ina;
     logic    sig_inb;
     logic    sig_en_i;
     logic    sig_out;
     logic    sig_en_o;
endinterface: simpleadder_ifCode 3.1: Interface module – simpleadder_if.sv

After we have an interface, we will need the top block. This block will be a normal SystemVerilog module and it will be responsible for:

• Connecting the DUT to the test class, using the interface defined before.
• Generating the clock for the DUT.
• Registering the interface in the UVM factory. This is necessary in order to pass this interface to all other classes that will be instantiated in the testbench. It will be registered in the UVM factory by using the uvm_resource_db method and every block that will use the same interface, will need to get it by calling the same method. It might start to look complex, but for now we won’t need to worry about it too much.
• Running the test.
  The source for the top block is represented in Code 3.2.

`include "simpleadder_pkg.sv"
`include "simpleadder.v"
`include "simpleadder_if.sv"
 
module simpleadder_tb_top;
     import uvm_pkg::*;
 
     //Interface declaration
     simpleadder_if vif();
 
     //Connects the Interface to the DUT
     simpleadder dut(vif.sig_clock,
                     vif.sig_en_i,
                     vif.sig_ina,
                     vif.sig_inb,
                     vif.sig_en_o,
                     vif.sig_out);
     initial begin
          //Registers the Interface in the configuration block
          //so that other blocks can use it
          uvm_resource_db#(virtual simpleadder_if)::set(.scope("ifs"), .name("simpleadder_if"), .val(vif));
 
          //Executes the test
          run_test();
     end
 
     //Variable initialization
     initial begin
          vif.sig_clock = 1'b1;
     end
 
     //Clock generation
     always
          #5 vif.sig_clock = ~vif.sig_clock;
     endmodule

Code 3.2: Top block – simepladder_tb_top.sv

A brief explanation of the code will follow:

• The lines 2 and 3 include the DUT and the interface into the top block, the line 5 imports the UVM library, lines 11 to 16 connect the interface signals to the DUT.
• Line 21 registers the interface in the factory database with the name simpleadder_if.
• Line 24 runs one of the test classes defined at compilation runtime. This name is specified in the Makefile.
• Line 34 generates the clock with a period of 10 time units. The time unit is also defined in the Makefile.

For more information about interfaces, you can consult the book “SystemVerilog for Verification: A Guide to Learning the TestBench Language Features“, chapter 5.3.

UVM - Defining The Verification Environment

Before understanding UVM, we need to understand verification.

Right now, we have a DUT and we will have to interact with it in order to test its functionality, so we need to stimulate it. To achieve this, we will need a block that generates sequences of bits to be transmitted to the DUT, this block is going to be named sequencer.

Usually sequencers are unaware of the communication bus, they are responsible for generating generic sequences of data and they pass that data to another block that takes care of the communication with the DUT. This block will be the driver.

While the driver maintains activity with the DUT by feeding it data generated from the sequencers, it doesn’t do any validation of the responses to the stimuli. We need another block that listens to the communication between the driver and the DUT and evaluates the responses from the DUT. This block is the monitor.

Monitors sample the inputs and the outputs of the DUT, they try to make a prediction of the expected result and send the prediction and result of the DUT to another block, the scoreboard, in order to be compared and evaluated.

All these blocks constitute a typical system used for verification and it’s the same structure used for UVM testbenches.

You can find a representation of a similar environment in Figure 2.1.

Figure 2.1: Typical UVM testbench

Usually, sequencers, drivers and monitors compose an agent. An agent and a scoreboard compose an environment. All these blocks are controlled by a greater block denominated of test. The test block controls all the blocks and sub blocks of the testbench. This means that just by changing a few lines of code, we could add, remove and override blocks in our testbench and build different environments without rewriting the whole test.

To illustrate the advantage of this feature, let’s imagine a situation where we are testing a another DUT that uses SPI for communication. If, by any chance, we want to test a similar DUT but with I2C instead, we would just need to add a monitor and a driver for I2C and override the existing SPI blocks, the sequencer and the scoreboard could reused just fine.

UVM Classes

The previous example demonstrates one of the great advantages of UVM. It’s very easy to replace components without having to modify the entire testbench, but it’s also due to the concept of classes and objects from SystemVerilog.

In UVM, all the mentioned blocks are represented as objects that are derived from the already existent classes.

A class tree of the most important UVM classes can be seen in Figure 2.2.

Figure 2.2: Partial UVM class tree

The data that travels to and from our DUT will stored in a class derived either from uvm_sequence_item or uvm_sequence. The sequencer will be derived from uvm_sequencer, the driver from uvm_driver, and so on.

Every each of these classes already have some useful methods implemented, so that the designer can only focus on the important part, which is the functional part of the class that will verify the design. These methods are going to addressed further ahead.

For more information about UVM classes, you can consult the document Accellera’s UVM 1.1 Class Reference.

UVM Phases

All these classes have simulation phases. Phases are ordered steps of execution implemented as methods. When we derive a new class, the simulation of our testbench will go through these different steps in order to construct, configure and connect the testbench component hierarchy.

The most important phases are represented in Figure 2.3.

Figure 2.3: Partial list of UVM phases

A brief explanation of each phase will follow:

• The build phase is used to construct components of the hierarchy. For example, the build phase of the agent class will construct the classes for the monitor, for the sequencer and for the driver.

• The connect is used to connect the different sub components of a class. Using the same example, the connect phase of the agent would connect the driver to the sequencer and it would connect the monitor to an external port.

• The run phase is the main phase of the execution, this is where the actual code of a simulation will execute.

• And at last, the report phase is the phase used to display the results of the simulation.

There are many more phases but none of them are mandatory. If we don’t need to have one in a particular class, we can just omit it and UVM will ignore it.

More information about UVM phasing can be consulted in Verification Academy’s UVM Cookbook, page 48.

UVM Macros

Another important aspect of UVM are the macros. These macros implement some useful methods in classes and in variables. they are optional, but recommended.

The most common ones are:

• `uvm_component_utils – This macro registers the new class type. It’s usually used when deriving new classes like a new agent, driver, monitor and so on.

• `uvm_field_int – This macro registers a variable in the UVM factory and implements some functions like copy(), compare() and print().

• `uvm_info – This a very useful macro to print messages from the UVM environment during simulation time.

This guide will not go into much detail about macros, their usage is always the same for every class, so it’s not worth to put much thought into it for now.

More information can be found in Accellera’s UVM 1.1 Class Reference, page 405.

 

SimpleAdder UVM Testbench

After a brief overview of a UVM testbench, it’s time to start developing one. By the end of this guide, we will have the verification environment from the Figure 2.4.

Figure 2.4: SimpleAdder Final Testbench

This guide will begin to approach the top block and the interface (chapter 3), then it will explain what data will be generated with the sequences and sequencers on chapter 4.

Following the sequencers, it will explain how to drive the signals into the DUT and how to observe the response in chapters 5 and 6 respectively.

Subsequently, it will explain how to connect the sequencer to the driver and the monitor to the scoreboard in chapter 7. Then it will show to build a simple scoreboard in chapter 8.

And finally, the test will be executed and analyzed.

The testbench can be run with the execution of a Makefile provided in the repository. As I mentioned previously, this Makefile uses Synopsys VCS but it should be easily modifiable to be executed with any HDL simulator.

UVM Tutorial - The DUT

This training guide will focus on showing how we can build a basic UVM environment, so the device under test was kept very simple in order to emphasize the explanation of UVM itself.

The DUT used is a simple ALU, limited to a single operation: the add operation. The inputs and outputs are represented in Figure 1.1.

Figure 1.1: Representation of the DUT’s inputs/outputs

This DUT takes two values of 2 bits each, ina and inb, sums them and sends the result to the output out. The inputs are sampled to the signal of en_i and the output is sent at the same time en_o is signalled.

The operation of the DUT is represented as a timing diagram and as a state machine in Figure 1.2.

Figure 1.2: Operation of the DUT

Below is the code for sample DUT

UVM Introduction

As digital systems grow in complexity, verification methodologies get progressively more essential. While in the early beginnings, digital designs were verified by looking at waveforms and performing manual checks, the complexity we have today don’t allow for that kind of verification anymore and, as a result, designers have been trying to find the best way to automate this process.

The SystemVerilog language came to aid many verification engineers. The language featured some mechanisms, like classes, covergroups and constraints, that eased some aspects of verifying a digital design and then, verification methodologies started to appear.

UVM is one of the methodologies that were created from the need to automate verification. The Universal Verification Methodology is a collection of API and proven verification guidelines written for SystemVerilog that help an engineer to create an efficient verification environment. It’s an open-source standard maintained by Accellera and can be freely acquired in their website.

By mandating a universal convention in verification techniques, engineers started to develop generic verification components that were portable from one project to another, this promoted the cooperation and the sharing of techniques among the user base. It also encouraged the development of verification components generic enough to be easily extended and improved without modifying the original code.

All these aspects contributed for a reduced effort in developing new verification environments, as designers can just reuse testbenches from previous projects and easily modify the components to their needs.

These series of webpages will provide a training guide for verifying a basic adder block using UVM. The guide will assume that you have some basic knowledge of SystemVerilog and will require accompaniment of the following resources:

• Accellera’s UVM User’s Guide 1.1

• Accellera’s UVM 1.1 Class Reference

• Verification Academy’s UVM Cookbook

This guide will be divided in 3 different parts:

• The first part, starting on chapter 1, will explain the operation of the device under test (DUT): the inputs, the outputs and the communication bus

• The second part, starting on chapter 2, will give a brief overview of a generic verification environment and the approach into verifying the DUT

• The third part, starting on chapter 3, will start to describe a possible UVM testbench to be used with our DUT with code examples. It’s important to consult to the external material in order to better understand the mechanism behind the testbench.

Transient Materials - Electronics that melt away

Imagine tossing your old phone in the toilet, watching it dissolve and then flushing it down, instead of having it wind up in a landfill. Scientists are working on electronic devices that can be triggered to disappear when they are no longer needed.

The technology is years away, but Assistant Professor Reza Montazami and his research team in the mechanical engineering labs at Iowa State University have published a report that shows progress is being made. In the two years they've been working on the project, they have created a fully dissolvable and working antenna.

"You can actually send a signal to your passport via satellite that causes the passport to physically degrade, so no one can use it," Montazami said.

The electronics, made with special "transient materials," could have far-ranging possibilities. Dissolvable electronics could be used in medicine for localizing treatment and delivering vaccines inside the body. They also could eliminate extra surgeries to remove temporarily implanted devices.The military could design information-gathering gadgets that could complete their mission and dissolve without leaving a trace.

The researchers have developed and tested transient resistors and capacitors. They’re working on transient LED and transistor technology, said Montazami, who started the research as a way to connect his background in solid-state physics and materials science with applied work in mechanical engineering.

As the technology develops, Montazami sees more and more potential for the commercial application of transient materials.

EDA Playground–An Awesome Online Tool

Many times we use the web to find code examples and tutorials. However, often the examples were incomplete. Sometimes they were missing the necessary code to hook the example into a real design. Other times, the code examples had syntax errors.

Sometime we are presented with a working design, with lines stripped out, but with undefined variables and dangling commas left in. Other times the code examples simply did not work on my simulator. All this resulted in endless frustration to us. I knew there had to be a better way, EDA Playground is one.

EDA Playground is a free web application that allows users to edit, simulate (and view waveforms), synthesize, and share their HDL code. Its goal is to accelerate the learning of design and testbench development with easier code sharing and with simpler access to simulators and libraries. EDA Playground is specifically designed for small prototypes and examples (it is not intended to be used for a full-blown FPGA or ASIC design).

EDA Playground gives engineers immediate hands-on exposure to simulating SystemVerilog, Verilog, VHDL, C++/SystemC, and other HDLs. All you need is a web browser. The goal is to accelerate learning of design/testbench development with easier code sharing, and with simpler access to EDA tools and libraries. EDA Playground is specifically designed for small prototypes and examples.

• With a simple click, run your code and see console output in real time. Pick another simulator version and run it again.
• View waves for your simulation using EPWave browser-based wave viewer.
• Save your code snippets. Share your code and simulation results with a web link. Perfect for web forum discussions or emails. Great for asking questions or sharing your knowledge.
• Quickly try something out
  • Try out a SystemVerilog feature before using it on your project.
  • Try out a library that you’re thinking of using.
  • Modify another engineer’s shared code and re-run it.
• Eliminate environment differences. Since the code always executes in the same environment, everyone will see the same result on a subsequent re-run.
• Browse and use a large repository of working code examples and templates.

 

Google To Develop Quantum Processors

Google was one of the early backers of a new approach to quantum computing adopted by a company called D-Wave. The company offers boxes that perform a process called quantum annealing instead of the more typical approach, which involves encoding information in a quantum state of a collection of entangled qubits. Although whatever D-Wave is doing is clearly quantum, it's still not clear that it offers a speedup compared to classical computers.

So rather than keeping all its eggs in D-Wave's basket, Google's "Quantum A.I. Lab" announced that it is starting a collaboration with an academic quantum computing researcher, John Martinis of the University of California-Santa Barbara. Martinis' group focuses on creating fault-tolerant qubits using a solid-state superconducting structure called a Josephson junction. By linking several of these junctions and spreading a single quantum state across them, it's possible to reach fidelities of over 99 percent when it comes to storing the quantum state.

Quantum states tend to be fragile and decay when they interact with their environment, so a lot of labs are working on making qubits that are more robust or have error correcting ability. Josephson junctions are one possible approach to this, but they have the advantage of being on familiar turf for computing companies, since they can be made by standard fabrication techniques (although they still need to be chilled to near absolute zero).

Google made it clear that it's not turning its back on D-Wave; the new work will be done in parallel. As for quantum computing itself, this is interesting news. A quick look at our past coverage makes it clear that there are a number of technologies that appear to be getting close to the point where they could be used to create a multi-qubit machine. Google's decision to push hard on one of these approaches could narrow the field—either by getting Josephson junctions to work or by showing that there are severe limitations to them.