Using the verifier as a means of rapid simulation of RTL projects. Introduction to UVM

This article will describe the installation and use of free software for simulating digital logic circuits in Verilog as alternatives to the commercial Incisve products from Cadense and ModelSim from MentorGraphics. Simulation comparison in ModelSim and Verilator. There will also be considered a universal verification methodology - UVM.

Installation software for SystemC UVM

1. Verifier

One of the languages ​​of the description of the equipment is verilog. In this language, you can write a module.

For example, there is a counting scheme:
')


Its code will look like this:

reg [3:0]counter; always @(posedge clk or posedge reset)   if(reset)    counter <= 4'd0;   else    counter <= counter + 1'd1; 

After the simulation, we get waveforms:



It can be seen that the next value, one greater than the previous one, will be written to the counter registers on the clock edge.

The written module may have a more complex structure, it will be difficult to check all the conditions manually. We need automated testing. To do this, you need to develop a test environment in one of the programming languages. The test environment will give us the opportunity to conduct a full functional test of the device.

To test the project code, in addition to languages ​​such as Verilog, SystemVerilog, Python (for writing models), you can use SystemC . SystemC is a system-level design and verification language implemented as an open source C ++ library.

One way Verilog modules are verified using SystemC is to translate verilog files in C ++. Verilator will help us in this.

Verilator is the fastest free Verilog HDL simulator that surpasses most commercial simulators. Verilator compiles the synthesized SystemVerilog (usually not the test bench code), as well as some SystemVerilog and Synthesis statements into single-threaded or multi-threaded C ++ or SystemC code. Verilator has been designed for large projects where simulation speed is paramount and is particularly well suited for generating executable processor models for embedded software development teams. Verilator is used to simulate many very large multi-million dollar gateway designs with thousands of modules and is supported by many suppliers of IP technologies, including IP from Arm and all well-known suppliers of RISC-V IP.

Verilator may not be the best choice if you expect a full-featured replacement for the NC-Verilog, VCS or another commercial Verilog simulator, or the Verilog behavioral simulator for a very small project. However, if you are looking for a way to port the synthesized Verilog to C ++ or SystemC, and your team is free to write only C ++ code, this is the free Verilog compiler for you.

To install the latest version on Ubuntu: download the archive from the link from the official site .

Install:

 #sudo apt-get install make autoconf g++ flex bison # Prerequisites unsetenv VERILATOR_ROOT # For csh; ignore error if on bash unset VERILATOR_ROOT # For bash tar xvzf verilator*.t*gz cd verilator* ./configure make sudo make install 

2. GTK Wave

GTKWave is a full-featured waveform viewer and also allows you to convert files from vcd format to fst format, more convenient and faster.

Install:

 sudo apt-get install gtkwave 

3. SYSTEMC

A system-level design and verification language implemented as an open source C ++ library.

As mentioned earlier, verilator supports systemc, so you need to create a project in which the testbench will be described on systemc, and the source files on the synthesized verilog. For this we need the libraries for the g ++ compiler provided by Accelera. The Accellera Systems Initiative is an independent, non-profit organization dedicated to the creation, support, promotion and promotion of system-level design, simulation and verification standards for use in the global electronics industry.

Download the archive:
http://accellera.org/images/downloads/standards/systemc/systemc-2.3.1a.tar.gz

Install:

 tar -xvf systemc-2.3.1a.tar.gz cd systemc-2.3.1a mkdir objdir sudo ./configure --prefix=/usr/local/systemc-2.3.1a/ sudo make sudo make install cd ../ 

4. UVM for SYSTEMC

This article will consider the project in which the UVM verification tool is implemented. Verification is the confirmation that the final product meets the predefined reference requirements. One of their verification tools can be tests. In order to run test sequences on models of real devices at the RTL description level, it is necessary to develop a test environment.

UVM - (Universal Verification Methodology) is a universal verification methodology, a standard that allows you to effectively develop and reuse the environment of checking IP-blocks. UVM is a verification methodology whose task is to organize an effective environment around the unit under test. Its advantages:

• clear structure in the form of dedicated blocks decisive concrete
• tasks;
• the ability to reuse blocks in subsequent projects;
• maximum possible verification automation;
• the fullest reporting information that allows for the occurrence of an error to quickly and accurately identify its causes and propose solutions.

UVM methodologies consist of two parts: a set of rules for constructing a test environment and a library of block presets for verification, for example, a text generator, a statistics collector, etc. The main advantage of UVM is versatility and compatibility with third-party environments.

Since systemc supports the UVM methodology, let's move on to installing the necessary libraries.

Download the archive:

https://www.accellera.org/images/downloads/drafts-review/uvm-systemc-1.0-beta2.tar.gz

Install:

 tar -xvf uvm-systemc-1.0-beta2.tar.gz cd uvm-systemc-1.0-beta2/ mkdir objdir sudo ./configure --prefix=/usr/local/systemc_uvm/ --with-systemc=/usr/local/systemc-2.3.1a sudo make sudo make install 

Create an alliance:

 sudo mkdir /usr/local/uvm_systemc_aliance 

Copy the contents of the / usr / local / uvm_systemc_aliance / and /usr/local/systemc-2.3.1/ folders into this folder.

Download the finished project at the link:
https://github.com/paprikun/SYSTEMC/

Open the folder verilator examples.
The rtl folder contains the device description. In this example, this is a PWM controller.
In the sim folder makefile file to build the project.
In the tb folder is the code for the verifier. The tb / uvm folder contains an example of a uvm environment. The main file is the entry point for testing, connecting the device under test with the uvm environment.
We try to build the project from the sim folder with the command make all. We see the error:

 /usr/local/uvm_systemc_aliance//include/systemc.h:120:16: error: 'std::gets' has not been declared using std::gets; 

Correct by replacing line 120:

 #if defined(__cplusplus) && (__cplusplus < 201103L) using std::gets; #endif 

Once again we try to run a testbench and stumble upon a warning:

 /usr/local/uvm_systemc_aliance//include/sysc/packages/boost/get_pointer.hpp:21:40: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations] template<class T> T * get_pointer(std::auto_ptr<T> const& p) 

Change auto_ptr to unique_ptr.

Build the project and simulation

Now that the libraries are installed and working properly, we are building the project: make all. The simu executive file should appear in the sim folder. This is an object created by the compiler. Run it with the command ./simu. The following should appear:

 SystemC 2.3.1-Accellera --- Jun 28 2019 11:39:29 Copyright (c) 1996-2014 by all Contributors, ALL RIGHTS RESERVED Universal Verification Methodology for SystemC (UVM-SystemC) Version: 1.0-beta2 Date: 2018-10-24 Copyright (c) 2006 - 2018 by all Contributors See NOTICE file for all Contributors ALL RIGHTS RESERVED Licensed under the Apache License, Version 2.0 UVM_INFO @ 0 s: reporter [RNTST] Running test ... simulation real time = 9 sec UVM_INFO uvm_default_report_server.cpp(666) @ 179490249010 ps: reporter [UVM/REPORT/SERVER] --- UVM Report Summary --- ** Report counts by severity UVM_INFO : 1 UVM_WARNING : 0 UVM_ERROR : 0 UVM_FATAL : 0 ** Report counts by id [RNTST] 1 UVM_INFO @ 179490249010 ps: reporter [FINISH] UVM-SystemC phasing completed; simulation finished 

When the simulation is finished, the wafeform recording is complete. The file simu.vcd can be opened by the gtkwave program:



To display the signals on the left, select SystemC, then hold Shift, select any signals, and click Append. Hints appear on the toolbar when you hover the cursor. Mouse scrolling works, you need to hold shift or cntrl.

There are also ways to convert this file to another, smaller size.

If there are modelsim do the conversion. In the terminal, enter the command vsim. In the modelsim terminal:

 vcd2wlf simu.vcd simu.wlf 

Or using gtkwave in linux terminal:

 vcd2lxt simu.vcd simu.lxt vcd2lxt2 simu.vcd simu.lxt2 

To compare the simulation time, a similar project was created, but for Modelsim . Folder modelsim_example. The UVM environment is similarly created. The syntax is similar despite the fact that different languages. If Modelsim is installed with uvm support, you can run it with make all.

In addition to the environment in both projects, real-time modeling was measured.

By the time it turned out the difference:

As can be seen from the table verilator has an advantage. The data are presented for PCs with 8 GB of RAM, 8-core processor, 800 MHz, one core load.

Compare the volume of files:

Here verilator loses, but you can experiment with the creation of waveforms and the depth of the trace, the recording period (the beginning and end of the waveform recording can be shifted). What file to work with you.

In the course of testing, in addition to the simulation itself, a discrepancy was found in reading input data from the in bus. If the data from the bus in change during the clk front, Modelsim read the data after the front, verilator before:

 input clk; input [7:0] in; reg [7:0] in_last_ ; ... always @(posedge clk) begin ... in_last_ <= in; ... end 

When testing, this point should be taken into account, as part of the test environment for different simulators will work differently.

Also, verilator does not take into account the “x” state of the signal and translates everything into “0”;

UVM TESTBENCH

Consider the test environment folder tb / uvm.

UVM testbench is an environment above the device. In this example, the device is a PWM controller. UVM environment:



As can be seen in the diagram, UVM consists of blocks (classes). Each unit performs its functions. The example shows one of the possible layouts of the test environment. The name and functionality of each class corresponds to the class from which it is inherited. Consider each class in more detail.

Environment- file env.h or env.svh. This is a class that can contain one or several agent classes in which three classes are connected: sequencer, driver, monitor. In the example, there is no agent, but its function is implemented in the env class. For the test, we need to write some sequence of actions - a sequence.

Let's go to the startup code for the sequence:

 sequence_[n]->start(sqr, NULL); 

Sequencer (sequencer) - file sequncer.h. In system verilog it turned out to use sequencer by default. A class that contains one or more sequences (sequence) (files sequence_a.h, sequence_a.svh). Each sequence represents a chain of actions. One such action may be sending a transaction. Transaction - transfer data from one class to another. The class in which transactions are described is bus_trans. Next will be a description of two classes, each of which ideologically has its own specific functions: driver and monitor.

Driver - file drv.h, drv.svh. A class that accepts transactions from a sequencer and translates them into signals. The driver serves as a sequencer assistant at a lower level. Consider sending a single parcel.

The sequence opens the transaction window, the driver detects this event and starts receiving data. Sequence waiting for a response from the driver. The driver simulates the signals for the device, then signals the sequencer that the window can be closed. The idea is that the sequencer works at a high level, and the driver at a lower level.

Signals are connected via the interface bus to the device. The interface is described in the files vip_if.h, vip_if.svh.

Next, you need to check whether the output signals with the expected. There are two solutions:

• Writing a model for the device
• Checking signals through a UVM agent

In the example, the second option is considered. To test the device at a functional level, you must verify the output with the expected. The requirement for the device was the correctness of the specified signal duty cycle and signal period. To monitor the output signals, a new class was written - Monitor (file monitor.h, monitor.svh). Usually, in a test environment, the monitor translates signals into transactions (to a higher level) and is sent to the comparison class - the scoreboard.

In this example, the signals are immediately checked. In case of a difference between the expected value and the measured one, the test stops.