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
evolution 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 language 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 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

SV TB Hierarchy
SV TB Hierarchy

SystemVerilog TestBench Architecture

SV TestBench block diagram
SV TestBench block diagram

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

❮ Previous Next ❯