SystemVerilog for verification

Imagine that you are given the job of building a house for someone. Where
should you begin? Do you start by choosing doors and windows, picking out
paint and carpet colors, or selecting bathroom fixtures? Of course not! First
you must consider how the owners will use the space, and their budget, so you
can decide what type of house to build. Questions you should consider are; do
they enjoy cooking and want a high-end kitchen, or will they prefer watching
movies in the home theater room and eating takeout pizza? Do they want a
home office or extra bedrooms? Or does their budget limit them to a basic
house?
Before you start to learn details of the SystemVerilog language, you need
to understand how you plan to verify your particular design and how this
influences the testbench structure. Just as all houses have kitchens, bedrooms,
and bathrooms, all testbenches share some common structure of stimulus generation
and response checking. This chapter introduces a set of guidelines and
coding styles for designing and constructing a testbench that meets your particular
needs. These techniques use some of the same concepts as shown in
the Verification Methodology Manual for SystemVerilog (VMM), Bergeron et
al. (2006), but without the base classes.
The most important principle you can learn as a verification engineer is:
“Bugs are good.” Don’t shy away from finding the next bug, do not hesitate to
ring a bell each time you uncover one, and furthermore, always keep track of
each bug found. The entire project team assumes there are bugs in the design,
so each bug found before tape-out is one fewer that ends up in the customer’s
hands. You need to be as devious as possible, twisting and torturing the
design to extract all possible bugs now, while they are still easy to fix. Don’t
let the designers steal all the glory — without your craft and cunning, the
design might never work!
This book assumes you already know the Verilog language and want to
learn the SystemVerilog Hardware Verification Language (HVL). Some of
the typical features of an HVL that distinguish it from a Hardware Description
Language such as Verilog or VHDL are
Constrained-random stimulus generation
Functional coverage
Higher-level structures, especially Object Oriented Programming
Multi-threading and interprocess communication
Support for HDL types such as Verilog’s 4-state values
Tight integration with event-simulator for control of the design
There are many other useful features, but these allow you to create testbenches
at a higher level of abstraction than you are able to achieve with an
HDL or a programming language such as C.