Contact / Report an issue

System Verilog

SystemVerilog


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

History of SystemVerilog
Evolution of SystemVerilog




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 language components
SystemVerilog Components

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 the generator and drives the packet level data inside a 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
module
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

TestBench Architecture
SystemVerilog TestBench hierarchy




SystemVerilog TestBench Architecture


SystemVerilog testbench architecture
SystemVerilog Testbench
Related Topics:


  SYSTEM VERILOG                                   


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


References: