Archive for February, 2015

UVM Tutorial 2 : Basic Building Blocks

February 25, 2015

UVM is generally built on a few basic blocks

  • DUT (Device Under Test)
  • Interface (An interface between DUT and test env)
  • Test environment using classes

BUILDING_BLOCKS_LARGE

Simple verilog to display “Hello World”

The module is named top but it can even be “xyz”.

The “initial” statement is what kicks off the run.

///////////////////////////////// VERILOG ONLY /////////////////////////////////

module top;

initial
$display(“Hello World !!”);  // verilog only
endmodule

////////////////////////////// END VERILOG ONLY /////////////////////////

Simple systemverilog code with UVM code to say “Hello World”

// usually test environments use the name top but one can call it anything because the environment is kicked off by the the code enclosed by “initial begin” and “end”.

///////////////////// SYSTEMVERILOG WITH UVM BEGIN ////////////////////////

hello_world_shortest_uvm

/////////////// SYSTEMVERILOG WITH UVM END //////////////////////////

Before we can code the equivalent systemverilog version, we need to understand how simulation phases work for systemverilog. In systemverilog, multiple steps or phases occur before the final simulation execution.  See the steps in the diagram below:

For now, we avoid a complex example and only use a few essential aspects of UVM to build up to the full fledged understanding of UVM phases in next section.

We need to take one step backwards and then take two steps forward by understanding the systemverilog point of view and then add UVM on top of that.

See next section on systemverilog coding of a counter to point out the main pieces of how a systemverilog testbench is constructed, coded and implemented : UVM Tutorial 3 : Systemverilog Testbench Principles

Advertisements

UVM Tutorial 1: Overview

February 24, 2015

What is UVM?

UVM = Universal Verification Methodology

UVM stands for Universal Verification Methodology as shown in the previous line.

UVM uses the language features of systemverilog verification to build testbenches using a specific methodology. The reasoning for a methodology is to enforce a common “way” or “method” to build testbenches so that reuse is maximized in a standardized way.  Anyway with knowledge of UVM doesn’t need to relearn the coding style of another person.  This increases the efficiency of building verification environments.  One of the major stumbling blocks to every increasing billion gate designs have been verification.  Thus, the specific effort put into creating this Universal Verification Methodology.  It has been shown by various studies that verification efforts can increases 1000x for a 10x increase in semiconductor transistors.  Think about it.  There can be up to 2**10 combinations of connections for a semiconductor chip design.

The efforts to standardize this verification methodology were pushed forward by Mentor Graphics and Cadence in early 2000s.  Eventually, Synopsys had to get onboard too.  See http://www.verificationacademy.com for more detailed information about UVM.

Think of UVM as specialized systemverilog libraries or technically macros that are called so that this universal verification methodology can be strictly followed and quickly adapted.

For those new to systemverilog, this language has been upgraded from Verilog-2001 to add object-oriented features to support design as well as verification.

Features of SYSTEMVERILOG Verification:

  • Functional Coverage
  • Randomization of Objects (with/without constraints)
    • rand addr_t addr
  • Methodology Libraries
    • Encapsulation of data and function
  • Object Oriented language constructs (just like C++)
    • classes
    • inheritance

Features of SYSTEMVERILOG Design (which are synthesizable):

  • Processes
    • assign statements
    • always_comb, always_ff
  • Operators
    •  . , .* Operator
    • Basic logic operations
  • Datatypes and Literals
    • Logic (4 state)
    • Typedef (user defined types)
    • Enumerations
    • Structures
    • Literals
  • Interfaces
    • Generic Interface
    • Interface ports
    • Interface modports
    • Parameterized Interfaces
  • For loop, Generate (with caution)
  • Disallowed SET
    • # delays
    • Initialization
    • No tasks and functions
    • Auto increment, decrement
    • Statically unknown bounds