Hardware Description Languages (HDL) like Verilog and VHDL are used to describe hardware behavior so that it can be converted to digital blocks made up of combinational gates and sequential elements. In order to verify that the hardware description in HDL is correct, there is a need for a language with more features in OOP that will support complicated testing procedures and is often called a Hardware Verification Language.
SystemVerilog is an extension of Verilog with many such verification features that allow engineers to verify the design using complex testbench structures and random stimuli in simulation.
|Ch#1: Introduction||Learn why SystemVerilog is needed, basic testbench structure and components in a verification environment|
|Ch#2: Data Types||Learn about all basic data types with complete examples and how to create more complex data structures|
|Ch#3: Control flows||Learn about all kinds of loops, if else, case statements and more on functions, tasks, events|
|Ch#4: Processes||Learn how to start multiple threads using fork join, join_any, join_none and how to disable and wait for certain threads|
|Ch#5: Communication||Learn about major communication mechanisms between components and threads like mailboxes and semaphores|
|Ch#6: Interface||Learn about how to connect DUT to testbench using interfaces, clocking blocks and modports|
|Ch#7: Class||Learn OOP building blocks like classes, polymorphism, inheritance, virtual methods, parameterized classes and more|
|Ch#8: Randomization||Learn all about randomization using constraints with concrete examples and use cases|
|Ch#9: Misc Topics||Learn about packages, program blocks, file handling and other operations in SystemVerilog|
|Ch#10: Coverage||Learn more on functional coverage, coverpoints, and covergroups|
|Ch#11: Testbench Examples||Learn how to use SystemVerilog constructs to build fully functional testbenches|
Why is Verilog not preferred ?
Back in the 1990's, Verilog was the primary language to verify functionality of designs that were small, not very complex and had less features. As design complexity increases, so does the requirement of better tools to design and verify it. SystemVerilog is far superior to Verilog because of its ability to perform constrained random stimuli, use OOP features in testbench construction, functional coverage, assertions among many others.
What is verification ?
Verification is the process of ensuring that a given hardware design works as expected. Chip design is a very extensive and time consuming process and costs millions to fabricate. Functional defects in the design if caught at an earlier stage in the design process will help save costs. If a bug is found later on in the design flow, then all of the design steps have to be repeated again which will use up more resources, money and time. If the entire design flow has to be repeated, then its called a respin of the chip.
What about Vera, e, and other similar HVL ?
They have been in use for some time. SystemVerilog can be considered an extension of Verilog (the most popular HDL), and it makes sense to verify a Verilog design in SystemVerilog. Also SystemVerilog supports OOP which makes verification of designs at a higher level of abstraction possible.
How is it used in verification ?
A hardware design mostly consists of several Verilog (.v) files with one top module, in which all other sub-modules are instantiated to achieve the desired behavior and functionality. An environment called testbench is required for the verification of a given verilog design and is usually written in SystemVerilog these days. The idea is to drive the design with different stimuli to observe its outputs and compare it with expected values to see if the design is behaving the way it should.
In order to do this, the top level design module is instantiated within the testbench environment, and design input/output ports are connected with the appropriate testbench component signals. The inputs to the design are driven with certain values for which we know how the design should operate. The outputs are analyzed and compared with the expected values to see if the design behavior is correct.
Consider a simple verilog design of a D-flip flop which is required to be verified. The functionality of DFF is that Q output pin gets latched to the value in D input pin at every positive clock edge, which makes it a positive edge-triggered flip-flop. Let us also assume that the flip-flop has an active-low reset pin and a clock.
// File : d_ff.v module d_ff (clk, resetn, q, d); input clk; input resetn; input d; output q; reg q; always @ (posedge clk) if (! resetn) q <= 0; else q <= d; endmodule
We need to build a testbench for this design inorder to drive some signal values to its input pins clk, reset, d and observe what the output looks like. By driving appropriate stimuli and checking results, we can be assured of its functional behavior. Synthesis tools can then convert this design into real hardware logics and gates.
// File : tb_top.sv module tb_top (); reg clk; reg resetn; reg d; wire q; // Instantiate the design d_ff d_ff0 ( .clk (clk), .resetn (resetn), .d (d), .q (q)); // Create a clock always #10 clk <= ~clk; initial begin resetn <= 0; d <= 0; #10 resetn <= 1; #5 d <= 1; #8 d <= 0; #2 d <= 1; #10 d <= 0; end endmodule
The file tb_top represents a simple testbench in which you have created an object of the design d_ff0 and connected it's ports with signals in the testbench. Then, you only need to assign or drive signals in the testbench and they will be passed on to the design.
Start learning SystemVerilog using links on the left side