• “Adder” TestBench example
  • Without Monitor and Scoreboard
  • With Monitor and Scoreboard
• “Memory” TestBench example
  • Without Monitor and Scoreboard
  • With Monitor and Scoreboard

 SYSTEM VERILOG

SystemVerilog Tutorial Interview Questions
SystemVerilog Quiz Code Library
About TestBench Adder TB Example
Memory Model TB Example How …. ?

 UVM

UVM Tutorial UVM Callback Tutorial
UVM Interview Questions About UVM TestBench
UVM TestBench Example UVM TLM Tutorial
UVM Event Tutorial UVM RAL Tutorial

 SYSTEM-C

SystemC Tutorial SystemC Interview Questions
SystemC Quiz

 ASIC VERIFICATION

ASIC Verification Interview Questions SOC Verification Interview Questions
AMBA AHB & AXI

 GENERAL

Basic GVIM/VIM Commands Verilog Codes

• AHB AXI Interview Questions

• • How to use UVM ” try_next_item(); “?
  • How to Generate a weighted random number?
  • How to display time in System Verilog?
  • How to clear the queue in System Verilog?

• How to generate unique random values in SystemVerilog?

Introduction to UVM

The Universal Verification Methodology (UVM) consists of class libraries needed for the development of well constructed, reusable SystemVerilog based Verification environment.
In simple words, UVM consists of a set of base classes with methods defined in it, the SystemVerilog verification environment can be developed by extending these base classes.
Now on will refer the UVM base classes as UVM Classes.

UVM Classes

UVM consists of three main types of UVM classes,

• uvm_object
• uvm_transaction
• uvm_component

uvm_object

• Core class based operational methods (create, copy, clone, compare, print, record, etc..), instance identification fields (name, type name, unique id, etc.) and random seeding were defined in it.
• All uvm_transaction and uvm_component were derived from the uvm_object.

uvm_transaction

• • Used in stimulus generation and analysis.

uvm_component

• Components are quasi-static objects that exist throughout the simulation.
• Every uvm_component is uniquely addressable via a hierarchical path name, e.g. “env.agent.driver”.
• The uvm_component also defines a phased test flow, that components follow during the course of the simulation. Each phase(build, connect, run, etc.) is defined by a callback that is executed in precise order.
• The uvm_component also defines configuration, reporting, transaction recording, and factory interfaces.

UVM Class Hierarchy

❮ Previous Next ❯

Evolution of SystemVerilog

SystemVerilog is an extension of Verilog.

Gateway Design Automation introduced Verilog as an evolutionary HDL in 1985.

Verilog language stemmed primarily from two earlier languages,

• HILO-2
• Occam parallel-processing language

In 1990, Cadence placed the Verilog language in the public domain, and Open Verilog International (OVI) formed to manage the language.

Cadence released the Verilog-XL user manual as the basis for the first Language Reference Manual. This manual became known as OVI Verilog 1.0.

In 1993, OVI released Verilog 2.0 to the IEEE, and in 1995 this became IEEE Std. 1364.

The IEEE working group released a revised standard in March of 2002, known as IEEE 1364-2001.

A revised version was released in 2003, known as IEEE 1364-2001 Revision C.

In 1998, the original developers of Verilog and HILO-2 formed Co-Design Automation and created Superlog Language.

Superlog’s goal is to integrate verification features into the Verilog language and create the first hardware design and verification language.

The new LRM for extensions to Verilog received the name SystemVerilog 3.0, which Accellera approved as a standard in June 2002.

Concurrently, Synopsys announced that it was donating several verification technologies to the SystemVerilog effort.

The donations included testbench constructs based on Vera, OpenVera assertions, Synopsys’ VCS DirectC simulation interface to C and C++, and a coverage application programming interface that provides links to coverage metrics.

On 2 June 2003, Accellera announced that its board and technical committee members had approved the SystemVerilog 3.1

In 2005, SystemVerilog was adopted as IEEE Standard 1800-2005

In 2009, the standard was merged with the base Verilog (IEEE 1364-2005) standard, creating IEEE Standard 1800-2009.

Error corrections and clarification of a few aspects of IEEE Std 1800-2009 lead to the release of IEEE Standard 1800-20012.

The current version is the IEEE standard 1800-2017.

SystemVerilog can be divided into two distinct based on its roles,

• SystemVerilog for design is an extension of Verilog-2005
• SystemVerilog for verification

SystemVerilog Components

SystemVerilog language is a combination of concepts of multiple languages.

SystemVerilog language components are,

• Concepts of Verilog HDL
• Testbench constructs based on Vera
• OpenVera assertions
• Synopsys’ VCS DirectC simulation interface to C and C++
• A coverage application programming interface that provides links to coverage metrics

SystemVerilog for Verification

Testbench or Verification Environment is used to check the functional correctness of the Design Under Test (DUT) by generating and driving a predefined input sequence to a design, capturing the design output and comparing with-respect-to expected output.

The verification environment can be written by using SystemVerilog concepts.

SystemVerilog TestBench

About TestBench

TestBench or Verification environment is a group of classes or components. where each component is performing a specific operation. i.e, generating stimulus, driving, monitoring, etc. and those classes will be named based on the operation.

TestBench Components

Name	Type	Description
transaction	class	Defines the pin level activity generated by agent (to drive to DUT through the driver) or the activity has to be observed by agent (Placeholder for the activity monitored by the monitor on DUT signals)
generator	class	Generates the stimulus (create and randomize the transaction class) and send it to Driver
driver	class	Receives the stimulus (transaction) from a generator and drives the packet level data inside the transaction into pin level (to DUT
monitor	class	Observes pin level activity on interface signals and converts into packet level which is sent to the components such as scoreboard
agent	class	An agent is a container class, which groups the class’s (generator, driver, and monitor) specific to an interface or protocol
scoreboard	class	Receives data items from monitors and compares them with expected values. Expected values can be either golden reference values or generated from the reference model
environment	class	The environment is a container class for grouping higher level components like agent’s and scoreboard
test	program	The test is responsible for, Configuring the testbench Initiate the testbench components construction process Initiate the stimulus driving
testbench_top	class	This is the topmost file, which connects the DUT and TestBench. It consists of DUT, Test and interface instances, the interface connects the DUT and TestBench

TestBench Hierarchy

SystemVerilog TestBench Architecture

SystemVerilog Related Topics:
SystemVerilog Tutorial Interview Questions
SystemVerilog Quiz Code Library
About TestBench Adder TB Example
Memory Model TB Example How …. ?
References:

• Rich, D. “The evolution of SystemVerilog” IEEE Design and Test of Computers, July/August 2003
• https://www.verilog.com/
• https://en.wikipedia.org/wiki/SystemVerilog

❮ Previous Next ❯