SESSION 7

Introduction To SystemVerilog
Prepared by Ahmed Eissa
[email protected]
CONTENTS

• Constrained random coverage driven verification

• Randomization in SystemVerilog
• Coverage in SystemVerilog
LAST SESSION RECAP

• Parameterized Classes
• Introduction to design patterns
• SV scheduling semantics
• virtual interfaces
 CONSTRAINED RANDOM
COVERAGE DRIVEN VERIFICATION
CONSTRAINED RANDOM COVERAGE
DRIVEN VERIFICATION

Stimulus

Constrain
Pure
Directed ed
random
random
CONSTRAINED RANDOM COVERAGE
DRIVEN VERIFICATION
• Direct stimulus:
– With directed testbenches,
individual features are verified
using individual testbenches.
– The stimulus is manually crafted
to exercise that feature.
– The response is verified against
the symptoms that would
appear should the feature not
be correctly implemented.
CONSTRAINED RANDOM COVERAGE
DRIVEN VERIFICATION
• Direct stimulus:
– You need to write tests that
cover all the features and find
the bugs.
– You will only discover bugs
that you expect
– Poor scalability
– Poor maintainability
– Use for small number of
testcases
CONSTRAINED RANDOM COVERAGE
DRIVEN VERIFICATION
▪ Pure random:
▪ randomize stimulus with no
constraints
▪ May generate corner testcases
that wouldn’t normally be
tested
▪ Usually generates highly
redundant scenarios
▪ May generate illegal stimulus
▪ Unreasonable for large
complex design
▪ How to measure verification
progress??
CONSTRAINED RANDOM COVERAGE
DRIVEN VERIFICATION
• Constrained random stimulus
– Steer randomization to interesting
scenarios with constraints and
probabilities
– Will create conditions that you have not
thought of when writing your
verification plan
– Create unexpected conditions and hit
corner case
– Reduce the bias introduced by
the verification engineer when coding
directed testbenches
– Takes longer time to ramp up compared
to direct testcases
– Better maintainability and scalability
 Challenge:
How to measure verification progress?

Solution:
Coverage
CONSTRAINED RANDOM COVERAGE
DRIVEN VERIFICATION
• The solution is to measure
progress against functional
coverage points that will identify
whether a feature has been
exercised.
• The objective becomes filling a
functional coverage model of
your design rather than writing
a series of testcases.
• You could fill this coverage
model using large directed
testbenches or random
testbench
CONSTRAINED RANDOM COVERAGE
DRIVEN VERIFICATION
• Notice that a random test often
covers a wider space than a
directed one
• This extra coverage may overlap
other tests, or may explore new
areas that you did not anticipate.
• you need to write more
constraints to keep random
generation from creating illegal
design functionality
• You need to write more
constraints to keep random
generation from creating illegal
design functionality
CONSTRAINED RANDOM COVERAGE DRIVEN VERIFICATION
RANDOMIZATION IN
SYSTEMVERILOG
RANDOMIZATION IN SYSTEMVERILOG

• Verilog has system function module try ();

reg read_write;
$random which can be used to reg [31:0] data;
generate random input vectors reg [31:0] address;
integer add_1, add_2, add_3;
– system function returns a new integer add ;
signed 32-bit random number
initial begin
– can be utilized to generate
different scenarios read_write = $random ; data = $random;address =
$random;
add_1 = $random % 10;
add_2 = {$random} %10 ;
add_3 = $unsigned($random) %10 ;
add = 40 + {$random} % (50 - 40);
$finish;

end
endmodule
RANDOMIZATION IN SYSTEMVERILOG

• The random stimulus generation in SystemVerilog is most useful

when used with OOP.
– You first create a class to hold a group of related random variables, and
then have the random-solver fill them with random values.
– You can still randomize individual variables, but this case is the least
interesting.
– True constrained-random stimuli is created at the transaction level, not
one value at a time.
RANDOMIZATION
IN
SYSTEMVERILOG
▪ rand: every time you randomize
the class, the variables are
assigned a value
▪ randc: random cyclic. so that the
random solver does not repeat a
random value until every possible
value has been assigned.
▪ Not all data types can be randc
▪ Simulators are only required to
implement randc variables up to 8
bits wide with 256 different values,
but most support much larger ranges
RANDOMIZATION
IN
SYSTEMVERILOG
• To steer randomization
to interesting scenarios,
we use constraints.
• A constraint is just a set
of relational expressions
that must be true for
the chosen value of the
variables
• Constraints are
declarative not
procedural
– they use {} instead of
begin-end pair
RANDOMIZATION
IN
SYSTEMVERILOG
• The randomize
function
– Assigns random values
to any variable in the
class that has been
labeled as rand or
randc
– makes sure that all
active constraints are
obeyed.
– if any fails, it returns
zero
RANDOMIZATION IN SYSTEMVERILOG

First simulation: module try ();

class packet;
p1.dst=3718514985 rand bit [31:0] src, dst, data[8];
randc bit [7:0] kind;
constraint c {
Second simulation: src>10;
src<15;
p1.dst=3718514985 }
endclass : packet
Third simulation: initial begin
packet p1=new();
p1.dst=3718514985 if(!p1.randomize())
$finish;
$display("p1.dst=%d",p1.dst);
Fourth simulation: end
endmodule
p1.dst=3718514985
 Challenge:
why do we get the same value when we randomize?

Solution:
Randomization in SystemVerilog is PRNG
RANDOMIZATION
IN
SYSTEMVERILOG
• The process of solving constraint expressions
is handled by the SystemVerilog constraint
solver.

• The solver chooses values that satisfy the

constraints.

• The values come from SystemVerilog’s PRNG,

that is started with an initial seed.

• If you give a SystemVerilog simulator the

same seed and the same testbench, it should
always produce the same results.
– Note that changing the tool version or
switches such as debug level can change
results.
– Changing the seed can be done using a run
time argument. Syntax depends on the tool
▪ For modelsim, use vsim <top
module name> -sv_seed <any
number>;
RANDOMIZATION IN SYSTEMVERILOG

First simulation with seed 100: module try ();

class packet;
p1.dst=2417578807 rand bit [31:0] src, dst, data[8];
randc bit [7:0] kind;
constraint c {
Second simulation with seed 200 : src>10;
src<15;
p1.dst=3333197725 }
endclass : packet
Third simulation with seed 300 : initial begin
packet p1=new();
p1.dst= 188739998 if(!p1.randomize())
$finish;
$display("p1.dst=%d",p1.dst);
Fourth simulation with seed 400 : end
endmodule
p1.dst=3374514894
RANDOMIZATION IN SYSTEMVERILOG

• If you give a SystemVerilog simulator the same seed and the same
testbench, it should always produce the same results.
I made a minimal
change in the
DUT/TB and now
Random stability
the output is
different. How did
that happen?
RANDOMIZATION IN SYSTEMVERILOG

• “Random stability” is a powerful tool that Hardware Verification

Languages (HVLs) put at our disposal, allowing us to repeat
specific parts of random simulations, even after significant
changes to the Device Under Test (DUT) and testbench.
• In SystemVerilog random stability can be defined as the resistance
of random results to code changes.
• Any SystemVerilog code that randomizes something is random
stable and instable to some degree. It is always possible to change
it in a way that won’t affect random, or in a way that will.
RANDOMIZATION IN SYSTEMVERILOG

• What can be randomized?

– any integral variable
– string can’t be randomized
– float numbers randomization isn’t allowed
– arrays
– classes
RANDOMIZATION IN SYSTEMVERILOG:

• There should be a maximum of class packet;

rand bit [31:0] src, dst, data[8];
only one operator in an randc bit [7:0] kind;
expression, such as <, <=, constraint c {
==, >=, or >. src>10;
– 10<src<15 is not allowed src<15;
}
• No assignments can be made endclass : packet

within expression
RANDOMIZATION IN SYSTEMVERILOG:

• With SystemVerilog inside class packet ;

rand bit [3:0] addr;
operator, random variables will
get values specified within the constraint addr_range { addr inside { [5:10]}; }
inside block. constraint addr_range { addr inside { 1,3,5,7,9}; }
– values within the inside block constraint addr_range { addr inside {1,3,[5:10],12,
[13:15]}; }
can be variable, constant or
range rand bit [3:0] start_addr;
– the inside block is written with rand bit [3:0] end_addr;
an inside keyword followed by constraint addr_range { addr inside
{[start_addr:end_addr]}; }
curly braces {}
endclass : packet
– inside can also be inverted with
“!” operator
constraint addr_range { addr !(inside {[5:10]}); }
RANDOMIZATION IN SYSTEMVERILOG:

• When weight based randomization addr dist { 2 := 5, [10:12] := 8 };

is required in Systemverilog, we
can use dist. //for addr == 2 , weight 5
// addr == 10, weight 8
• dist is an operator, it takes a list of
// addr == 11, weight 8
values and weights, separated
// addr == 12, weight 8
by := or :/ operator.
– The := operator assigns the
specified weight to the item, or if addr dist { 2 :/ 5, [10:12] :/ 8 };
the item is a range, specified weight
to every value in the range.
//for addr == 2 , weight 5
– The :/ operator assigns the specified
// addr == 10, weight 8/3
weight to the item, or if the item is a
range, specified weight/n to every // addr == 11, weight 8/3
value in the range. where n is the // addr == 12, weight 8/3
number of values in the range.
RANDOMIZATION IN SYSTEMVERILOG

• Implications can be done in two

ways:
– implication operator
– if..else block
• The expression A->B is
equivalent to the expression (!A
|| B). When the implication
operator appears in a constraint,
the solver picks values for A and
B so that the implication is true
– When A is true, B must be true,
– When A is false, B can either be
true or false
RANDOMIZATION IN SYSTEMVERILOG

• The equivalence operator <->

is bidirectional. A<−>B is
defined as ((A->B)
– When A is true, then B must be
true
– When B is true, then B must be
true
RANDOMIZATION IN SYSTEMVERILOG

• The if-else operator is a great

way to choose between
multiple expressions
RANDOMIZATION IN SYSTEMVERILOG

• You can guide distribution with

solve..before
• The solve…before constraint
does not change the solution
space, just the probability of
the results.
RANDOMIZATION IN SYSTEMVERILOG
RANDOMIZATION IN SYSTEMVERILOG

• An array is randomized if and only if there was any constraint on

the array size
– Without putting a constraint on the size, the array wouldn’t be
randomized even if it was “rand”
– Why?
▪ without constraining the size, what would be the solution space? how much
memory would that consume

• Fixed array are randomized automatically as their size is know at

compile time
RANDOMIZATION IN SYSTEMVERILOG:

• Elements of arrays can be class fs_array;

rand bit [7:0] array1[6];
constrained also using the
foreach keyword constraint array_c {
foreach(array1[i])
array1[i] == i;
}

function void display();

$display("array1 = %p",array1);
endfunction

endclass
RANDOMIZATION IN SYSTEMVERILOG:

• Array reduction and class fs_array;

manipulation methods can also rand bit [7:0] array1[6];
be used in randomization
constraint array_c { array1.sum() == 30;}

function void display();

$display("array1 = %p",array1);
endfunction

endclass
RANDOMIZATION IN SYSTEMVERILOG

• Sometimes you need to perform an

action immediately before every
randomize call or immediately
afterwards.
• On calling randomize(), pre_randomize()
and post_randomize() functions will get
called before and after the randomize call
respectively
• They are created by default for every
class that has any random variables
– Users can override the pre_randomize() and
post_randomize() functions
 RANDOMIZATION IN SYSTEMVERILOG
class packet;
rand bit [7:0] addr;
randc bit [7:0] data;

//pre randomization function • What is the expected

function void pre_randomize(); output?
$display("Inside pre_randomize");
endfunction

//post randomization function

function void post_randomize(); Inside pre_randomize
$display("Inside post_randomize"); Inside post_randomize
$display("value of addr = %0d, data = %0d",addr,data); value of addr = 110, data =
endfunction
endclass
129

module rand_methods;
initial begin
packet pkt;
pkt = new();
pkt.randomize();
end
endmodule
RANDOMIZATION IN SYSTEMVERILOG

• Remember that float random class real_c;

real r;
number generation is not
rand integer i;
allowed rand integer j;
– To work around that, $bitstoreal function void post_randomize;
and $realtobits r = $bitstoreal({i,j});
– or you could scale $display("%e ",r);
class C; endfunction
rand int unsigned multiplier;
real result, A, B; endclass

function post_tandomize(); program real_p_111;

real_c obj = new();
result = A +
(B-A)*(real'(multiplier)/32'hffffffff) initial
repeat(5)
endfunction
void'(obj.randomize());
endclass endprogram
RANDOMIZATION IN SYSTEMVERILOG

• Constraints can also be class packet;

rand bit [7:0] addr;
declared when an object is randc bit [7:0] data;
randomized endclass
– Called inline constraints
module rand_methods;
– randomized with {}
initial begin
packet pkt;
pkt = new();
pkt.randomize() with {data[1:0]==2'b00;};
end
endmodule
RANDOMIZATION IN SYSTEMVERILOG
class packet;
rand bit [3:0] addr;
• constraints can also be turned constraint addr_range { addr inside {5,10,15}; }
off using the constraint_mode endclass

– constraint_mode(0) will turn off module static_constr;

the constraint initial begin
packet pkt;
– constraint_mode(1) will turn on pkt = new();

the constraint $display("Before Constraint disable");

– constraints are turned on by repeat(2) begin //{

pkt.randomize();
default $display("\taddr = %0d",pkt.addr);
end //}

//disabling constraint
pkt.addr_range.constraint_mode(0);

$display("After Constraint disable");

repeat(2) begin //{
pkt.randomize();
$display("\taddr = %0d",pkt.addr);
end //}
end
endmodule
RANDOMIZATION IN SYSTEMVERILOG

• You can use randcase to make a weighted choice between several

actions, without having to create a class and instance
RANDOMIZATION IN SYSTEMVERILOG
module stim;
• SV also allows randomization outside bit [15:0] addr;
classes using: bit [31:0] data;
– $urandom(): returns a new 32-bit function bit gen_stim();
random number each time it is called bit success, rd_wr;
– The $urandom_range(maxval, minval) success = randomize( addr, data,
function returns an unsigned integer rd_wr ) with {data[1:0]==2'b00}; // call
within a specified range. std::randomize
– std::randomize(): enables users to return rd_wr ;
randomize data in the current scope,
endfunction
without the need to define a class or
instantiate a class object. ...
▪ inline constraints can be added here also endmodule
RANDOMIZATION IN SYSTEMVERILOG
 Challenge:
What to randomize when you are randomizing?
easy,
randomiz
e input
ports
 Challenge:
What to randomize when you are randomizing?
easy,
randomiz
e input
ports
RANDOMIZATION IN SYSTEMVERILOG

• Randomizing only input or data fields in general has very low

payback in terms of bugs found
– You only find data-path bugs, perhaps with bit-level mistakes.
– The challenging bugs are in the control logic
• You need to randomize all decision points in your DUT. Everywhere
control paths diverge, randomization increases the probability that
you’ll take a different path in each test case.
RANDOMIZATION IN SYSTEMVERILOG

• You need to think broadly about all design input such as the
following items.
– Device configuration
– Environment configuration
– Primary input data
– Encapsulated input data
– Protocol exceptions
– Delays
COVERAGE
 Challenge:
How to measure verification progress?

Solution:
Coverage
COVERAGE

• Coverage is defined as the

percentage of verification
objectives that have been met.
• It is used as a metric for Coverag
evaluating the progress of a e
verification project in order to
reduce the number of Function
simulation cycles spent in Code
al
verifying a design coverag
Coverag
e
e
CODE COVERAGE

• Code coverage
– Automatically extracted from the design code
– Code coverage measures how much of the “design Code” is exercised.
– Tool generated
– Usually used to identify holes in the verification that has been performed
– sometimes called structural coverage
– Has many types
▪ Statement coverage: Have all lines of code been executed?
▪ Branch coverage: Have all branches in the code been taken?
▪ Expression coverage: Have all expressions that could affect a branch been executed?
▪ State / Transition coverage: Have all states of a state machine been active and have all
transitions between states been traversed?
▪ Toggle coverage: Have all variables or all bits of all variables changed state and or been
through all transitions?
CODE COVERAGE: STATEMENT
COVERAGE
• Statement coverage can also
be called block coverage or
line coverage, where a block is
a sequence of statements that
are executed if a single
statement is executed.
CODE COVERAGE: STATEMENT
COVERAGE
• Expression coverage measures
the various ways decisions
through the code
CODE COVERAGE: FSM COVERAGE

• FSM coverage has two types:

– state coverage: which states
have been visited
– transitions: did all possible
transition happen
 • What Does 100 Percent Code Coverage Mean?
– The entire design implementation was executed.
– it does not provide an indication, in any way, about
CODE the correctness or completeness of the verification
suite.
COVERAGE – That doesn’t mean the design is complete.
▪ What if the designer forget to implement a
feature from the specs? would code coverage be
affected
FUNCTIONAL COVERAGE

▪ Functional coverage is another technology to help

ensure that a bad design is not hiding behind passing
testbenches
▪ Functional coverage records relevant metrics (e.g.,
packet length, instruction opcode, buffer occupancy
level) to ensure that the verification process has
exercised the design through all of the interesting
values.
▪ Whereas code coverage measures how much of the
implementation has been exercised, functional
coverage measures how much of the original
design specification has been exercised
▪ High functional coverage does not necessarily
correlate with high code coverage.
FUNCTIONAL COVERAGE

• What Does 100 Percent Functional Coverage Mean?

– It indicates completeness of the test suite, not correctness of design.
– Functional coverage indicates which interesting and relevant conditions
were verified. response to those conditions.
– Functional coverage metrics are only as good as the functional
coverage model you have defined. An
– overall functional coverage metric of 100 percent means that you’ve
covered all of the coverage points you included in the simulation.
– It makes no statement about the completeness of your functional
coverage model.
COVERAGE COMPARISON
COVERAGE

• If the functional coverage is high but the code coverage is low, what does that mean?
– Your tests are not exercising the full design,
– Perhaps your coverage model is inadequate
– it may be time to go back to the hardware specifications and update your verification plan. Then
you need to add more functional coverage points to locate untested functionality.
– The design code may contain dead code
▪ Dead code is code that can’t be exercised such as a default case inside a full case
▪ You may need to add coverage exclusions

• If the functional coverage is low but the code coverage is high, what does that mean?
– Your testbench is giving the design a good workout
– You are unable to put it in all the interesting states.
– Your design itself might be missing some features
FUNCTIONAL COVERAGE

• Functional coverage is a user-defined metric that measures how much of the

design specification, as enumerated by features in the test plan, has been
exercised.
• It can be used to measure whether interesting scenarios, corner cases,
specification invariants, or other applicable design conditions have been
observed, validated and tested.
• The SystemVerilog functional coverage constructs enable:
– Coverage of variables and expressions, as well as cross coverage between them.
– Automatic as well as user-defined coverage bins.
– Associate bins with sets of values, transitions, or cross products.
– Filtering conditions at multiple levels.
– Events and sequences to automatically trigger coverage sampling.
– Procedural activation and query of coverage.
– Optional directives to control and regulate coverage.
FUNCTIONAL COVERAGE:
COVERGROUP
• The covergroup construct covergroup cov_grp @(posedge clk);
encapsulates the specification cov_p1: coverpoint a;
of a coverage model. Each endgroup
covergroup specification can
include the following
components: cov_grp cov_inst = new();
– A clocking event that
synchronizes the sampling of
coverage points
– A set of coverage points
– Cross coverage between
coverage points
– Optional formal arguments
– Coverage options
FUNCTIONAL COVERAGE:
COVERGROUP
• The covergroup construct is a user-defined type. The type
definition is written once, and multiple instances of that type can
be created in different contexts.
• Similar to a class, once defined, a covergroup instance can be
created via the new() operator.
• A covergroup can be defined in a module, program, interface, or
class
– it’s recommended to develop coverage groups inside classes
FUNCTIONAL COVERAGE
FUNCTIONAL COVERAGE
FUNCTIONAL COVERAGE

• The two major parts of covergroup cov_grp @(posedge clk);

covergroup are cov_p1: coverpoint a;
– when the data is sampled endgroup
– what data values are sampled
• Sampling can be done in two cov_grp cov_inst = new();
ways
– exactly calling <covergroup
covergroup cov_grp;
name>. sample() from a
procedural code cov_p1: coverpoint a;
– using a control event endgroup

cov_grp cov_inst = new();

@(abc) cov_inst.sample();
FUNCTIONAL COVERAGE

• A covergroup can contain one or more module cov;

coverage points
logic clk;
• A coverage point can be an integral
variable or an integral expression logic [7:0] addr;
• Each coverage point is associated with logic wr_rd;
“bin”
• On each sample clock simulator will
increment the associated bin value
covergroup cg @(posedge clk);
• Bins can be generated automatically c1: coverpoint addr;
• An automatically single bin will be created c2: coverpoint wr_rd;
for each value of the coverpoint variable endgroup : cg
range. These are called automatic, or
implicit, bins. cg cover_inst = new();
• For an “n” bit integral coverpoint variable, ...
a 2^n number of automatic bins will get endmodule
created.
FUNCTIONAL COVERAGE: BINS

• bins can also be specified module cov;

logic clk;
explicitly logic [7:0] addr;
logic wr_rd;
• A separate bin is created for
each value in the given range covergroup cg @(posedge clk);
c1: coverpoint addr { bins b1 = {0,2,7};
of variable or a single/multiple bins b2[3] = {11:20};
bins for the rage of values. bins b3 = {[30:40],[50:60],77};

• Bins are explicitly declared bins b4[] = {[79:99],[110:130],140};

bins b5[] = {160,170,180};
within curly braces { } along bins b6 = {200:$};
with the bins keyword followed bins b7 = default;}
c2: coverpoint wr_rd {bins wrrd};
by bin name and variable endgroup : cg
value/range, immediately after
cg cover_inst = new();
the coverpoint identifier. ...
endmodule
FUNCTIONAL COVERAGE: BINS

bins b1 = {0,2,7 }; //bin “b1” increments for addr = 0,2 or 7

bins b2[3] = {11:20}; //creates three bins b2[0],b2[1] and b2[3].and The 11 possible values are
//distributed as follows: (11,12,13),(14,15,16) and (17,18,19,20) respectively.
bins b3 = {[30:40],[50:60],77}; //bin “b3”increments for addr = 30-40 or 50-60 or 77
bins b4[] = {[79:99],[110:130],140};//creates three bins b4[0],b4[1] and b4[3] with values 79-99,50-60 and 77
respectively
bins b5[] = {160,170,180}; //creates three bins b5[0],b5[1] and b5[3] with values 160,170 and 180
respectively
bins b6 = {200:$}; //bin “b6” increments for addr = 200 to max value i.e, 255.
default bin; // catches the values of the coverage point that do not lie within any of the defined
bins.
FUNCTIONAL COVERAGE: BINS

• bins can also be specified for covergroup cg @(posedge clk);

c1: coverpoint addr{ bins b1 = (10=>20=>30);
transitions bins b2[] = (40=>50),
(80=>90=>100=>120);
bins b3 = (1,5 => 6, 7);}
c2: coverpoint wr_rd;
endgroup : cg

bins b1 = (10=>20=>30); // transition from

10->20->30
bins b2[] = (40=>50),(80=>90=>100=>120); // b2[0] =
40->50 and b2[1] = 80->90->100->120
bins b3 = (1,5 => 6, 7);} // b3 = 1=>6 or 1=>7
or 5=>6 or 5=>7
FUNCTIONAL COVERAGE: CROSS
COVERAGE POINTS
• Cross Coverage is specified covergroup cg @(posedge clk);
between the cover points or c1: coverpoint a;
variables. Cross coverage is
specified using the cross construct. c2: coverpoint b;
• Expressions cannot be used directly
c1Xc2: cross c1,c2;
in a cross; a coverage point must endgroup : cg
be explicitly defined first.
• In the second example, each
coverage point has 16 bins, namely bit [3:0] a, b;
auto[0]…auto[15]. The cross of a covergroup cov @(posedge clk);
and b (labeled aXb), therefore, has
256 cross products, and each cross aXb : cross a, b;
product is a bin of aXb. endgroup
FINAL REMARKS
ASSIGNMENTS

▪ Reading assignment: Study chapter six

of SystemVerilog for Verification Book
by Chris Spear
▪ Optional Reading assignment: Study chapter
nine of SystemVerilog for Verification Book by
Chris Spear
▪ Reading assignment:
▪ SystemVerilog Constraints: Appreciating What Yo
u Forgot in School to Get Better Results
▪ Optional:
The Top Most Common SystemVerilog Constrain
ed Random Gotchas
▪ Optional:
I Didn’t Know Constraints Could Do That!
▪ Optional:
UVM Random Stability Don’t leave it to chance
COMMON INTERVIEW QUESTION

• What is the difference between directed testing, random design,

constrained random and constrained random coverage driven?
• What is the difference between rand and randc?
• How to randomize an array in SystemVerilog?
• What is random stability?
• What are the main types of code coverage?
• What is functional coverage? why is it important?
• What does reaching 100% code coverage mean?
• What does reaching 100% functional coverage mean?
• When to end verification?
REFERENCES

• Main textbook: SystemVerilog for Verification by Chris Spear

• Writing Testbenches using System Verilog
• SystemVerilog Language Reference Manual
• https://verificationguide.com/systemverilog/systemverilog-
functional-coverage/
THANK YOU