Introduction:

System Verilog is a Hardware description and verification language used to design, simulate, and test electronic designs. It is a superset of Verilog and standardized as IEEE 1800. It enhances a lot of powerful Verilog features. Its verification functionality is based on open Vera. It also uses a lot of constructs and features of C/C++. It is a class-based object-oriented programming language that has a lot of non-synthesizable constructs to provide a lot of flexibility for verification engineers to verify complex designs. It offers constructs that can be used to simulate HDL designs and validate them using high-level test cases.

History of System Verilog:

System Verilog got its origins in 2002 when the startup business Co-Design Automation donated the Superlog language to Accellera. The majority of the verification functionality is built using Synopsys's Open Vera language. 2005 saw the adoption of System Verilog as IEEE Standard 1800-2005. The standard was combined in 2009 with the foundational Verilog (IEEE 1364-2005) standard to become IEEE Standard 1800-2009. IEEE standard 1800-2017 is the current version.

There are two unique functions that the System Verilog feature set can play: All capabilities of Verilog-2005 are available in System Verilog, which is an extension of that language used for register-transfer level (RTL) design. As a result, System Verilog includes Verilog in its subset. System Verilog, which is used for verification, is more closely connected to C++ than Verilog and makes considerable use of object-oriented programming approaches. Most of the time, these constructs may not be synthesized.

Why System Verilog?

In the 1990s, Verilog was the main language used to test the functionality of small, simple, and feature-limited designs. The need for better design and verification tools grows along with design complexity, hence System Verilog was introduced, which adds a robust, user-defined type system to Verilog for its enhancement. Moreover, it improves strong typing capabilities, particularly for user-defined types. Compared to Verilog, System Verilog is a more general-purpose language.  It gives users the ability to define and package reusable functionality that is not already present in the Verilog.

Figure 1: Features of System Verilog

Design verification and coverage analysis are common uses of System Verilog, which Verilog cannot handle as effectively. As shown in figure 1, Constrained random generation, assertion, and functional coverage constructs are among the features that System Verilog seeks to offer. Assertion-based verification, interface abstraction, and packaging are further capabilities added to System Verilog. System Verilog is a great tool for verifying the edge cases of the logic because of its object-oriented structure, which is exceedingly challenging or nearly impossible using Verilog.

Advantages of System Verilog:

• System Verilog enhances Verilog’s features, and it provides a lot of extended features as well.
• System Verilog’s constraints help to carry out randomized testing with random stimulus generation.
• System Verilog introduces some new data types for readability and to make efficient codes.
• System Verilog’s program block reduces the possibility of race conditions between the design and the Testbench by having a separate region of execution for it.
• System Verilog’s functional coverage would give a complete analysis of scenarios and corner cases that have been covered and uncovered.
• System Verilog’s Assertion will ensure there is no violation of protocol as per the design specification.
• DPI in system Verilog allows direct inter-language function calls between the system Verilog and other high-level programming languages like C, C++ etc.

The above section clearly emphasizes the importance of System Verilog as a Hardware Design and Verification language. It contains a variety of approaches that we may use for efficient verification. It has a separate region for the test bench and design. The further section will be explaining about the verification, test bench, and test bench architecture.

Verification is the process of making sure a specific hardware design performs as or not. The process of designing a chip is exceedingly intensive, time-consuming, and expensive to produce. Cost savings can be achieved by identifying functional design flaws at an early stage in the design cycle.

Testbench is used to check the functional correctness of the Design by generating and driving a predefined input sequence to a design, capturing the design output, and comparing it with respect to the expected output. The verification environment is a collection of classes that execute tasks, such as generating stimuli, driving, and monitoring. These classes are named according to their function. The hierarchy for the testbench is illustrated in Figure 2:

Figure 2: Hierarchy for System Verilog Testbench

Components of Testbench:

The System Verilog test bench has various components as shown in Figure 3 to perform a specific task.

Figure 3: Components of System Verilog Testbench

1. Transaction: class specifies the pin level activity produced by the agent or the activity must be observed by an agent.
2. Generator: class is responsible for the generation of different input stimuli to be driven to DUT.
3. Driver: class receives the stimuli (transaction) from a generator and transmits the transaction's packet level data at the pin level (to the DUT).
4. Interface: Includes design signals that can be driven or monitored.
5. Monitor: class observes activity at the pin level on interface signals and translates it to packet level for transmission to components like the scoreboard.
6. Agent: is a container class, which groups the generator, driver, and monitor classes according to a certain interface or protocol.
7. Scoreboard: this class compares the design's output obtained from the monitor with the expected values. The expected values may be generated from the reference model, or these are golden reference values.
8. Environment: The environment is a container class that Includes each of the verification components mentioned above.
9. Test: Includes the environment that can be modified using various configuration parameters. The test is responsible for: setting up the test bench, starting the process of building the test bench components, and starting the stimulus driving.