System Verilog Intro
System Verilog was introduced in 2002 by Accellera. It was adopted as IEEE standard in 2005. Later, this standard was merged with the Verilog standard in 2009 and was standardised as IEEE 1800-2009.
System Verilog is an extended version of Verilog with lots of verification capabilities taken from Open Vera. The most significant change in System Verilog is that this language is based on OOPs (object-oriented programming) concept. System Verilog brought many of the verification capabilities like functional coverage, assertions into a single language. Many companies have adopted System Verilog as part of the verification medium.
Automated Testbench
An automated testbench is required to verify the complex design, where it can compare the output from the DUT to some reference output. This testbench is required as a manual comparison for outputs is not possible for complex designs. Discussing the testbench in detail is out of the scope of this article. However, we will see it in brief so that the advantages of System Verilog can be realised.
In testbench, there are various components, namely
- Transaction – This is the abstraction of all the signals that are present in DUT. If there are many signals in DUT, let us suppose 50 signals, then it is challenging to manage 50 variables and send them between different components. Encapsulating them into a single object makes it more manageable.
- Generator – This component generates different input stimuli for the DUT.
- Driver – This component drives the various signal according to the stimulus generated by the generator.
- Monitor – This component monitors the i/p and o/p signal and samples them at some event. This sampled signal is compared with the reference output.
- Scoreboard – This component is responsible for comparing the sampled packet with the reference one.
- Environment – This encapsulates all the components of the test bench into one entity.
Need for System Verilog
We have seen that there are various components in a complex, automated test bench, and Verilog only has modules to define a particular entity. There is no way to write these components and combine them separately (as modules are static). Thus, many companies used custom solutions to implement the OOPs concept. With System Verilog, this problem was solved as the language itself provided the OOPs behaviour required for writing complex test benches.
Another big problem in Verilog was the race around condition between the design and the test bench. As we know, in Verilog, there is only four-event semantics, and both the design and test bench would run on the same regions. Seldom this leads to a race-around condition, and ultimately the verification is not correct.
Assertions are an essential part of verification as it helps us to verify the behaviour of the design. Verilog does not inherently support assertion-based verification. Although the assertion verification could be achieved in Verilog, the codes become very complicated. System Verilog Assertions provides an easy way to carry out assertion-based verification along with functional verification.
These are just some of the main advantages of System Verilog. As we proceed further in System Verilog, we will see many more advantages that System Verilog provides over Verilog.
Verilog vs System Verilog
In brief, Verilog can be differentiated from System Verilog as follows:
Verilog | System Verilog |
---|---|
Verilog is mainly used for writing RTL codes. | System Verilog was mainly designed to ease the process of writing test bench, though this can also be used to write RTL. |
Does not based on the concept of OOPs | Based on the OOPs concept |
There are 4 event regions | There are 9 event regions |
All data types are of 4-state type | Introduced new data types to hold 2 state values. |
There are lot more additions done in System Verilog which is hard to summarize in one article. In future articles, we will see in detail the additions done in System Verilog.