Chapter 6-Testbench

Chapter 6
Component Test
and Verification
Modified from Prof. Navabis Lectures
Component Test and Verification

6.1 Testbench
6.1.1 Combinational circuit testing
6.1.2 Sequential circuit testing
6.2 Testbench Techniques
6.2.1 Test data
6.2.2 Simulation control
6.2.3 Limiting data sets
6.2.4 Applying synchronized data
6.2.5 Synchronized display of results
6.2.6 An interactive testbench
6.2.7 Random time intervals
6.2.8 Buffered data application
2

6.3 Design Verification
6.4 Assertion Verification
6.4.1 Assertion verification benefits
6.4.2 Open verification library
6.4.3 Using assertion monitors
6.4.4 Assertion templates
6.5 Text Based Testbenches
6.6 Summary

This chapter shows:
How Verilog language constructs can be used for application of
data to a module under test (MUT)
How module responses can be displayed and checked
The first part: Data application and response monitoring
The second part: The use of assertion verification for giving a better
observability to our design modules
Testbench
Verilog simulation environments provide two kinds of display of
simulation results:
Graphical
Textual
Some also provide tools for editing input test data to a design module
that is being tested.
These tools are referred to as Waveform Editors.
Waveform editors have 2 problems:
Usually are good only for small designs.
Each simulation environment uses a different procedure for
waveform editing.
This problem can be solved by use of Verilog Testbenches.
Testbench
A Verilog Testbench is:
A Verilog module
Instantiates Module Under Test (MUT).
Applies data to MUT.
Monitors the output.
A module and its testbench forms a Simulation Module in which MUT
is tested for the same data regardless of what simulation environment
is used.
Testbench
Testbench
Combinational
Circuit
Testing
Sequential
Circuit
Testing
Combinational Circuit Testing

Testbench
Combinational
Combinational
Circuit
Circuit
Testing
Testing
Sequential
Circuit
Testing

module alu_4bit (a, b, f, oe, y, p, ov, a_gt_b,
a_eq_b, a_lt_b);
input [3:0] a, b;
Data Inputs
input [1:0] f;
Function Input
input oe;
Data Output
output [3:0] y;
output p, ov, a_gt_b, a_eq_b, a_lt_b;
// . . .
Compare Outputs
Parity
Overflow
endmodule
Output
Output
alu_4bit Module Declaration

9

module test_alu_4bit;
reg [3:0] a=4'b1011, b=4'b0110;
reg [1:0] f=2'b00;
reg oe=1;
wire [3:0] y;
wire p, ov, a_gt_b, a_eq_b, a_lt_b;
Variables
connecting to
Inputs
Variables
connecting to
Outputs
alu_4bit cut( a, b, f, oe, y, p, ov, a_gt_b,

a_eq_b, a_lt_b );
.......................
.......................
This instantiation associates
Testbench for alu_4bit
local regs and wires to the

ports of the alu_4bit module
10

Application of data to
the b data imput
.......................
and oe output-enable
initial begin
Initial
#20 b=4'b1011;
Block
#20 b=4'b1110;
Waits
#20 b=4'b1110;
for
#80 oe=1'b0;
80ns
#20 $finish;
end
always #23 fAfter
= 20ns
f +1;
endmodule
the simulation
is finished
Every 20 ns
A new value is
assigned to b
The $finish statement
reached at 160 ns.
Disablesisthe
At this time all
ALU Output
active
blocks
by setting
oe toprocedural
0
Application
stop and
of simulation
data
Allows
to the f input.
terminates.
effects of the last
f ischange
increment
by 1
input
to be
every
23 ns.
shown
in
simulation results
Testbench for alu_4bit (Continued)
11

f changes every 23ns
Throughout the
causing various
simulation a
ALU functions
remains constant
to be examined
At 140 ns
oe changes to 0
causing the y output
become Z
ALU Simulation Results
12
Sequential Circuit Testing

Testbench
Combinational
Circuit
Testing
Sequential
Sequential
Circuit
Circuit
Testing
Testing
13
Testing sequential circuits involves synchronization of Clock with other

data inputs.
14

The circuit has a poly parameter
that determines its signature and
module #(parameter [3:0] poly=0) misr data
(input
clk,rst,
compression.
input [3:0] d_in, outputWith
regeach
[3:0]
);
clock ad_out
new signature
will be calculated with the new
data and existing misr register
always @( posedge clk )
data.
if( rst )
d_out =4'b0000;
else
d_out = d_in ^ ({4{d_out[0]}} & poly) ^
{1'b0,d_out[3:1]};
endmodule
misr Sequential Circuit
15

module test_misr;
reg clk=0, rst=0;
reg [3:0] d_in;
wire [3:0] d_out;
misr #(4'b1100) MUT ( clk, rst, d_in, d_out );
Specification of the poly parameter
...........................
...........................
A Testbench for misr
16

The timing is so chosen to
cover at least one positive
..........................
clock edge
initial begin
#13 rst=1'b1;
#19 d_in=4'b1000;
#31 rst=0'b0;
#330 $finish;
end
In order to reduce chance

of several inputs changing
at the same time,
we usually use prime numbers
The initial timing
block generates
a positive
of sequential
circuit
d_in data for
input
pulse on rst that begins
at
13
ns
and
inputs.
is initialized ends at 63 ns.
to 4b1000
d_in input is assigned a
new value
every 37 ns.
Generate data on
always #37 d_in = d_in + 3;
clk
always #11 clk = ~clk;
Togglesd_in
everyand
11ns
endmodule
A Testbench for misr (Continued)
17
Testing misr
18
Testbench Techniques
Testbench
Techniques
Test
Data
Simulation
Control
Limiting
Data Sets
Applying
Synchronized Data
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Intervals
Buffered
Data Application
19
module moore_detector (input x, rst, clk, output z );
parameter [1:0] a=0, b=1, c=2, d=3;
reg [1:0] current;
Synchronous Reset Input

if ( rst ) current <= a;
..........................
..........................
endmodule
101 Moore Detector for Test
20
..........................
if ( rst ) current = a;
else case ( current )
a : current <= x ? b
b : current <= x ? b
c : current <= x ? d
d : current <= x ? b
default : current <=
endcase
assign z = (current==d) ?
endmodule
: a
: c
: a
: c
x;
;
;
;
;
z output becomes 1
in state d when
a sequence of 101
is detected on x
1'b1 : 1'b0;
101 Moore Detector for Test (Continued)

21
Test Data
Testbench
Techniques
Test
Data
Simulation
Control
Limiting
Data Sets
Applying
Synchronized Data
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Intervals
Buffered
Data Application
22
Test Data
module test_moore_detector;
reg x, reset, clock;
wire z;
moore_detector MUT ( x, reset, clock, z );
............................
............................
endmodule
Basic Data Generation
23
Test Data
Initial Block
............................
For initializing the reg variables
............................
initial begin
Four
clock=1'b0; x=1'b0; reset=1'b1;
Procedural Blocks
end
initial #24 reset=1'b0;
The waveform generated on x
Generates a signal with a
always #5 clock=~clock;
may or may not be able to test
period of 10ns on clock
our machine for
always #7 x=~x;
endmodule
Generates
signal
x with101 sequence.
a on
correct
Variables
used inathe
left-handperiod of 14ns
sides in theaprocedural
blocks
Periods
are declared as
reg of clock and x can be
changed to make this happen
Basic Data Generation (Continued)
24
Simulation Control
Testbench
Techniques
Test
Data
Simulation
Simulation
Control
Limiting
Data Sets
Applying
Synchronized Data
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Intervals
Buffered
Data Application
25
Simulation Control
Simulation
Control Tasks
Another testbench
for
are $stop and $finish
moore_detector
which
reg x=0, reset=1, clock=0;
wire z;
adds another initial block

that stops the simulation
at 189 ns.

always #7 x=~x;
initial #189 $stop;
endmodule
The first time the flow of

a procedural block
reaches $stop at 189 ns,
simulation stops.
A stopped simulation
can be resumed.
Testbench with $stop Simulation Control

26
Simulation Control
wire z;
Another testbench for

moore_detector with
$finish Control Task

............................
............................
endmodule
Testbench with $finish Simulation Control
27
Simulation Control
This testbench combines
the initial blocks of
deactivating reset and
............................
simulation control into
............................
one initial block.
initial begin
#24 reset=1'b0;
Simulation terminates at 165 ns.
#165 $finish;
end
A finished simulation
cannot be resumed.
always #7 x=~x;
endmodule
Testbench with $finish Simulation Control (Continued)
28
Limiting Data Sets

Testbench
Techniques
Test
Data
Simulation
Control
Limiting
Limiting
Data Sets
Applying
Synchronized Data
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Intervals
Buffered
Data Application
29
Limiting Data Sets

Instead of setting
simulation time limit,
a testbench can put a limit
on the number of data
put on inputs of a MUT.
This will z
also);
be able to
moore_detector MUT ( x, reset, clock,
stop simulation
from
Cause
clock to toggle
running
13 timesindefinitely.
every 5 ns
wire z;

initial repeat(13) #5 clock=~clock;
initial repeat(10) #7 x=$random;
InCause
large xcircuits,
random
to receive
Generates random data on the x
data
is more
random
datauseful
endmodule
input of the circuit.
for
data inputs
10 times
every 7than
ns for
Testbench Using repeat to Limit Data Sets
control signals.
30
Applying Synchronized Data

Testbench
Techniques
Test
Data
Simulation
Control
Limiting
Data Sets
Applying
Applying
Synchronized Data
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Intervals
Buffered
Data Application
31
Where several sets of data are to be applied:

Synchronization of data with the system clock becomes difficult.
Changing the clock frequency would require changing the timing
of all data inputs of the module being tested.
32

This testbench uses an
event control statement to
synchronize data applied
delay
This loop waitstofor
the3ns
xThis
with
the clock.
wire z;
makes
it possible to use
positive edge
of the
this it,
testbench
for
clock, and 3 ns after
a
moore_detector uut( x, reset, clock,
z );
simulating
new random
data is post-synthesis
designs as well as
generated for x.
behavioral descriptions
initial #24 reset=0;
initial repeat(13) #5 clock=~clock;

initial forever @(posedge clock) #3 x=$random;
endmodule
Synchronizing Data with Clock
Testbench
Guarantees
that Delays:
Setup
changing
of and
dataHold
and Time
clock do not coincide.
33
Synchronized Display of Results

Testbench
Techniques
Test
Data
Simulation
Control
Limiting
Data Sets
Applying
Synchronized Data
Synchronized
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Intervals
Buffered
Data Application
34

wire z;
This testbench uses an

event control statement for
synchronized observation
MUT
1nsof
after
the outputs
positive or
edge
internal
signals.
of the clock,
when
the circuit
output iszsupposed
to have
moore_detector MUT ( x, reset, clock,
);
initial
initial
initial
initial
its new stable value, the z

output is displayed using the
$displayb task.
#24 reset=0;
repeat(13) #5 clock=~clock;
forever @(posedge clock) #3 x=$random;
forever @(posedge clock) #1 $displayb(z);
endmodule
Testbench Displaying Output
This testbench is also usable for

the post-synthesis
simulation of moore_detector
35

wire z;
This testbench is developed

for observing states of
moore_detector

............................
............................
endmodule
Testbench Displays Design Variables when they change
36

Display occurs when an
............................
event occurs on one of the
$monitor to display
............................
variables of theUses
tasks
current register
Starts
$monitor task
initial
#24 reset=0;arguments.
Hierarchial
in the
background
initial
repeat(19) #5 clock=~clock; In binary
Event Based
Naming
format
initial forever @(posedge clock) #3 x=$random;

initial $monitor("New state is %b and occurs
at %t", MUT.current, $time);
always @(z) $display("Output changes at %t to %b",
With z);
the
$time,
time unit
Sensitive to z
current state and z output
endmodule
Flow Based
Uses $display to display
are displayed when they
output when they change
Testbench Displays Designthe
Variables
(Continued)
receive
new values.
37
New state is x
Output changes
New state is 0
New state is 1
New state is 2
Output changes
New state is 3
and
at
and
and
and
at
and
occurs at
0
50 to 0
occurs at
occurs at
occurs at
50
250
850
950 to 1
occurs at
950
Test Results of Testbench of Fig. 6.14
38
An Interactive Testbench
Testbench
Techniques
Test
Data
Simulation
Control
Limiting
Data Sets
Applying
Synchronized Data
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Intervals
Buffered
Data Application
39
module moore_detector (input x, start, rst, clk,
output z );
parameter a=0, b=1, c=2, d=3, e=4;
reg [2:0] current;
A 1101 Moore detector

With 5 states

............................
............................
............................
endmodule
Moore Sequence Detector Detecting 1101
40
else if ( ~start ) current <= a;
If start becomes 0
the machine resets to
a : current <= x ? b : a ;
initial state a
b : current <= x ? c : a ;
c : current <= x ? c : d ;
d : current <= x ? e : a ;
e : current <= x ? c : a ;
default: current <= a;
endcase
assign z = (current==e);
Output becomes 1 in state e
endmodule
Moore Sequence Detector Detecting 1101 (Continued)
41
reg x=0, start, reset=1, clock=0;
wire z;
moore_detector MUT ( x, start, reset, clock, z );
............................
............................
............................
endmodule
42
To get the machine started
initial begin
#24 reset=1'b0; start=1'b1;
wait(z==1'b1);
Waits for z to become 1,
#11 start=1'b0;
After it restarts the machine
#13 start=1'b1;
repeat(3) begin
Repeats the process of
#11 start=1'b0;
starting the machine and
#13 start=1'b1;
waiting for z to become 1
3 more times
wait(z==1'b1);
end
After 50 ns simulation is stopped
#50 $stop;
end
An Interactive Testbench (Continued)

43
............................
............................
............................
always blocks to generate
always #7 x=$random;
clock and x input
endmodule
An Interactive Testbench (Continued)
44
Waveform Resulted by the Interactive Testbench
45
reg x=0, start, reset=1, clock=0;
wire z;
initial begin
#24 reset=1'b0; start=1'b1;
end
............................
endmodule
Interactive Testbench Using Display Tasks
46
When current becomes e
z is displayed
............................
Hierarchical Naming
Displays as soon as program
always begin Displays
: Output_Display
the old value of z
flow reaches it
To observe wait(MUT.current == MUT.e);
output within$display ("$display task shows: The output is
a state
%b", z);
$strobe ("$strobe task shows: The output is
%b", z);
#2 $stop;
A simulation clock cycle
Waits
for all simulation event
end
after e is detected,
to complete before displaying
z becomes 1 and is displayed
always #7 x=$random;
endmodule
Interactive Testbench Using Display Tasks (Continued)
47
Random Time Intervals

Testbench
Techniques
Test
Data
Simulation
Control
Limiting
Data Sets
Applying
Synchronized Data
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Time
Random
Intervals
Intervals
Buffered
Data Application
48

reg x, start, reset, clock;
wire z;
This testbench uses

random wait times for
assigning values to x
reg [3:0] t;
............................
............................
endmodule
Testbench using Random Time Intervals
49

Nonblocking assignments
cause intra-assignment
delay values to be regarded
as absolute timing values
initial begin:running
clock <= 1'b0; x <= 1'b0;
reset <= 1'b1; reset <= #7 1'b0;
start <= 1'b0; start <= #17 1'b1;
repeat (13) begin
Waits for 13 complete clock
@( posedge clock );
pulses before it de-asserts the
@( negedge clock );
start and finishes the simulation
end
start=1'b0;
Waits until the propagation of all
#5;
signals be completed
$finish;
end
Testbench using Random Time Intervals (Continued)
50

............................
This block generates data on
............................
x as long as the $finish
............................
statement is not reached
always begin
Generates Random data on t
t = $random;
#(t) x=$random;
Uses t to delay assignments
end
of random values to x
endmodule
Testbench using Random Time Intervals (Continued)
51
Buffered Data Application

Testbench
Techniques
Test
Data
Simulation
Control
Limiting
Data Sets
Applying
Synchronized Data
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Intervals
Buffered
Buffered
Data Application
Application
Data
52

reg x=0, rst, start, clk=0;
wire z;
reg [18:0] buffer;
This testbench uses a

buffer to hold data to
be applied to the
MUT data input
moore_detector MUT ( x, start, rst, clk, z );

............................
............................
endmodule
Testbench Applying Buffered Data
53

We are sure a correct
19-bit buffer is initialized with test data
sequence is applied to
............................
our MUT and can
initial buffer = 19'b0001101101111001001;
more easily check for
initial begin
expected results.
rst=1'b1; start=1'b0;
Start and stop control of the state
#29 rst=1'b0;
machine
Each bit of the buffer is shifted
out
#29 start=1'b1;
onto the x input of MUT
#500 $stop;
1ns after the positive edge of clock
end
always @(posedge clk) #1 {x, buffer} = {buffer,x};
always #5 clk = ~clk;
As data is shifted, buffer is rotated in
endmodule
order for the applied buffered data to

Testbench Applying Buffered Data (Continued) be able to repeat
54
Design Verification
Formal verification:
A way of automating design verification by eliminating testbenches
and problems associated with their data generation and response
observation.
Tools do not perform simulation, but come up with a Yes/No
answer for every property the design is being checked for.
Eliminating data generation and response observation
Assertion verification:
Reduce or eliminate efforts needed for analyzing output responses
While the design is being simulated with its testbench data,
assertion monitors continuously check for correct design behavior.
In conditions that the design is misbehaving, the monitor is said to
fire to alert the designer of the problem.
55
Assertion Verification
Assertion
Verification
Assertion
Verification
Benefits
Open
Verification
Library
Using
Assertion
Monitors
Assertion
Templates
56
Assertion Verification
Unlike simulation, here in-code monitors issue a message if something
happens that is not expected.
In Verilog, monitors are modules.
The present set of assertion monitors are available in a library referred
to as OVL (Open Verification Library)
For using assertions designer compiles OVL and his or her own
assertion library into a simulation library.
If a signal does not have a value expected by a monitor, the assertion
monitor displays a message and the time that the violation of the
property has occurred.
57
Assertion Verification Benefits

Assertion
Verification
Assertion
Assertion
Verification
Benefits
Benefits
Open
Verification
Library
Using
Assertion
Monitors
Assertion
Templates
58
Assertion Verification Benefits

Ways in which assertion monitors are helpful:
Designer Discipline: With placing an assertion in a design, a
designer is disciplining him/her-self to look into the design more
carefully and extract properties.
Observability: Assertions add monitoring points to a design that
make it more observable.
Formal Verification Ready: Having inserted assertion monitors to a
design, readies it for verification by a formal verification tool.
Executable Comments: Assertion monitors can be regarded as
comments that explain some features or behavior of a design.
Self Contained Designs: A design with assertion monitors has the
design description and its test procedure all in one Verilog module.
59
Open Verification Library

Assertion
Verification
Assertion
Verification
Benefits
Open
Open
Verification
Library
Library
Using
Assertion
Monitors
Assertion
Templates
60
Assertions
61

Assertion module name
comes first.
Assert_name
An Assertion is placed
in code like a module
instantiation.
Followed by static_parameters
like vector size and options
#(static-parameters)
Any Unique name is
allowed
instance-name
Assertion Module Instantiation
(dynamic-arguments);
Reference and monitor signals and
other dynamic arguments
62
Using Assertion Monitors

Assertion
Verification
Assertion
Verification
Benefits
Open
Verification
Library
Using
Using
Assertion
Assertion
Monitors
Assertion
Templates
63
Using Assertion Monitors

Assertion
Monitors
assert_always
assert_change
assert_one_hot
assert_
cycle_sequence
assert_next
64
assert_always
Assertion
Monitors
assert_always
assert_change
assert_one_hot
assert_
cycle_sequence
assert_next
65
assert_always
If the test expression fails,
the assertion fires and its
corresponding message
(msg) is displayed
Continuously checks
its test_expr to make
sure it is always
true on the edge of
the
specified clock (clk)
assert_always
#( severity_level, property_type,
msg, coverage_level )
instance_name ( clk, reset_n, test_expr )
General Format for assert_always Assertion Monitor
66
assert_always
This counter counts

between 0 and 9
module BCD_Counter (input rst, clk,

output reg [3:0] cnt);
always @(posedge clk) begin
if (rst || cnt >= 10) cnt = 0;
else cnt = cnt + 1;
The assertion monitor
end
here uses severity_level 1
assert_always #(1, 0, "Err: Non BCD Count, 0)
AA1 (clk, 1'b1, (cnt >= 0) && (cnt <= 9));
Indicates that the assertion is
endmodule
to be monitored at all times
BCD with assert_always
The test expression:

The monitor checks that on
every rising edge of clk, cnt
must be between 0 and 9
67
assert_always
module BCD_Counter_Tester;
reg r, c;
wire [3:0] count;
BCD_Counter UUT (r, c, count);
initial begin
r = 0; c = 0;
end
initial repeat (200) #17 c= ~c;
initial repeat (03) #807 r= ~r;
endmodule
Even though checking

simulation results is
done in a semi-automatic
fashion, test data
generation is still done
manually by the designer
BCD Counter Testbench

68
assert_change
Assertion
Monitors
assert_always
assert_change
assert_one_hot
assert_
cycle_sequence
assert_next
69
assert_change
Verifies that within a
given number of clocks
after the start event, the
test expression changes.
assert_change
#( severity_level, width, num_cks,
action_on_new_start, property_type,
instance_name ( clk, reset_n, start_event,
test_expr )
General Format for assert_change Assertion Monitor
70
assert_change
A shift register that walks
a 1 with every clock.
module Walking_One (input rst, clk, output reg [7:0] wo);
always @(negedge clk) begin
if (rst) wo <= 8'b10000000;
A 1 is loaded into the left-most
else wo <= {wo[0], wo[7:1]};
bit of wo with the rst signal
end
assert_change #(1, 1, 7, 0, 0, "Err: Bit 0 is not

changing, 0)
AC1 (~clk, ~rst, (rst==0), wo[0]);
assert_one_hot #(1, 8, 0, "Err: Multiple active
bits, 0)
AOH (~clk, ~rst, wo);
endmodule
Walking One Circuit with Assertions

71
............................
............................
Check
that @(negedge
from the time that
always
clk) begin
(rst ==
and while
if 0)(rst)
wo(~rst),
<= it8'b10000000;
takes at most 7 negative clock
else wo
<=
{wo[0],
wo[7:1]};
7 for the number of clocks
1
for
the
length
of
the
edges for wo[0] to change.
that change is to occur
end
test expression
changing, 0)
AC1 (~clk, ~rst, (rst==0), wo[0]);
............................
Falling edge of clk
Test Expression

72
assert_change
module Walking_One_Tester ();
reg rst=0, clk=0;
wire [7:0] walking;
It is the responsibility of
the testbench developer to
make sure enough data is
applied to cause design
errors to trigger assertion
monitors.
Walking_One MUT (rst, clk, walking);

initial repeat (223) #7 clk= ~clk;
initial repeat (15) #109 rst= ~rst;
endmodule
Walking_One Testbench
73
rst
assert_change
When rst becomes 1,

the falling edge of the
clock puts a 1 into wo[7]
When
becomes 0, this
1 starts walking, it takes 7
clock edges for this 1 to
walk to bit 0 of wo.
Signals connected to
Walking-One Test Results
wo[7] to wo[0]
74
assert_one_hot
Assertion
Monitors
assert_always
assert_change
assert_one_hot
assert_
cycle_sequence
assert_next
75
assert_one_hot
Checks that while the
monitor is active, only
one bit of its n-bit test
expression is 1.
assert_one_hot
#( severity_level, width, property_type,
General Format for assert_one_hot Assertion Monitor
76
assert_one_hot
module Walking_One (input rst, clk, output reg [7:0] wo);
if (rst) wo <= 8'b10000000;
else wo <= {wo[0], wo[7:1]};
end

changing, 0)
AC1 (~clk, ~rst, (rst==0), wo[0]);
bits, 0)
endmodule

77
assert_one_hot
............................
............................
if (rst) wo <= 8'b10000000;
else wo <= {wo[0], wo[7:1]};
end
Test expression width
............................
bits, 0)Test expression
Makes the checking

active only when rst is 0
78
assert_one_hot
The mem.dat
that
module gray_counter (input [3:0] d_in,
input file
clk,
rst, ld, contains
outputconsecutive
reg [3:0]
q);
Gray code numbers is
read into mem.
reg [3:0] mem[0:15];
reg [3:0] im_q;
initial $readmemb("mem.dat", mem);
always @( d_in or ld or q ) begin: combinational

With each clock, the next
if( ld )
Gray count is looked up
im_q = d_in;
from mem.
else
im_q = mem[q]; end
............................
Gray
Code Counter
79
assert_one_hot
............................
always @( posedge clk ) begin: register
if( rst )
q <= 4'b0000;
Consecutive Gray code
In order to check for the
else
numbers are only
correct Gray code sequencing,
q
<=
im_q;
different in one bit, their
some auxiliary logic have been
end XOR must be one-hot.
used to prepare the test expression
reg [3:0] old; always @(posedge clk) old <= q;

assert_one_hot #(1, 4, 0, "Err: Not Gray, 0)
AOH (~clk, ~rst, (old ^ q));
endmodule
Gray Code Counter (Continued)
80
assert_cycle_sequence
Assertion
Monitors
assert_always
assert_change
assert_one_hot
assert_
cycle_sequence
assert_next
81
Checks for a sequence of
events in a given number
of clocks.
#( severity_level, num_cks,
necessary_condition,
property_type,
instance_name ( clk, reset_n, event_sequence)
Like
other assertion
monitors, this
General Format for assert_cycle_sequence
Assertion
Monitor
monitor has an enabling input that

is usually driven by the inactive level
of a circuits reset input.
82
After the reset state,
the machine searches for
110 sequence.
When 110 is
received the next
2 clock cycles
take the machine
back to state a
e=4
a=0
0
1
1
1 0
b=1
0
d=3
1
0
0
c=2
0
A Sequencing State Machine
83
module Sequencing_Machine (input x, start, rst, clk,
output z );
parameter a=0, b=1, c=2, d=3, e=4;
reg [2:0] current;

............................
............................
Verilog Code of Sequencing_Machine
84
............................
else if ( ~start ) current <= a;
a : current <= x ? b : a ;
b : current <= x ? c : a ;
c : current <= x ? c : d ;
d : current <= e ;
e : current <= a ;
default: current <= a;
endcase
Verilog Code of Sequencing_Machine (Continued)
85
This monitor is setup

to check if the machine
reaches
states d and then
For checking that the
last state
state e,ifthen the next
............................
of the sequence is reached
will move the
the previous states are clock
reached
assign
z
=
(current==e);
Number of states in sequence
machine into state a.
in the specified sequence.
#(1, 3, 0, 0, "Err: State sequence not
followed, 0)
ACS (clk, ~rst, {(current==d),
(current==e), (current==a)});
assert_next #(1, 2, 1, 0, 0, "Err: Output state
The reached,
sequence of states
not
0) to verify
AN1 (clk, ~rst, (current==c && x==0),
(z==1));
endmodule
86
If the machine enters state

4 (e ), then state 0 (a ) is
entered.
Sequencing_Machine State Transitions
87
assert_next
Assertion
Monitors
assert_always
assert_change
assert_one_hot
assert_
cycle_sequence
assert_next
88
assert_next
Verifies that starting and
an ending events occur
with a specified number
of clocks in between.
assert_next
#( severity_level, num_cks,
check_overlapping,
check_missing_start, property_type,
instance_name ( clk, reset_n, start_event,
test_expr)
General Format for assert_next Assertion Monitor
89
assert_next
Verifying that there are
two clock cycles between
............................
the time that current
assign z = (current==e);
becomes c while x is 0,
and the time that z
#(1, 3, 0, 0, "Err: State sequence
not 1.
becomes
0)
Numberfollowed,
of clock
ACS
~rst,
cycles (clk,
between the
events{(current==d),
(current==e), (current==a)});
assert_next #(1, 2, 1, 0, 0, "Err: Output state
not reached, 0)
AN1 (clk, ~rst, (current==c && x==0),
(z==1));
Start Expression
endmodule
Test Expression

90
Assertion Templates
Assertion
Verification
Assertion
Verification
Benefits
Open
Verification
Library
Using
Assertion
Monitors
Assertion
Assertion
Templates
Templates
91
Assertion Templates
Hardware features designers may need to verify, and how assertions

can be used for their verification
92
Assertion Templates
Assertion
Templates
Reset
Sequence
Initial
Resetting
Implication
Valid States
93
Reset Sequence
Assertion
Templates
Reset
Reset
Sequence
Initial
Resetting
Implication
Valid States
94
Reset Sequence
Often controllers have a
resetting sequence that
with certain sequence of
module Sequencing_Machine (input x,inputs,
start,
rst, ends
clk,
the machine
Verifies output
that if in three
z state
); it is in.
of what
clocks, x is 0,
parameter a=0, b=1, c=2, consecutive
d=3, e=4;
in the fourth clock the
// . . .
current state of the
machine becomes a.
#(1, 4, 0, 0, "Err:Resetting does not occur")
ACS2 (clk, ~rst, {(x==0), (x==0), (x==0),
(current==a)});
// . . .
endmodule
Assertion Reset Sequence
95
Initial Resetting
Assertion
Templates
Reset
Sequence
Initial
Resetting
Resetting
Implication
Valid States
96
Initial Resetting
For verification of many
sequential circuits becomes
A Mealy Machine
necessary to check for resetting the
circuit using a synchronous or
module mealy_detector (input x, rst, clk, output z);
asynchronous reset input.
localparam [1:0]
reset = 0, // 0 = 0 0
got1 = 1, // 1 = 0 1
got10 = 2; // 2 = 1 0
reg [1:0] current;
............................
............................
............................
endmodule
Hard-Reset Assertion
97
Initial Resetting
............................
always @( posedge clk ) begin
if (rst) current <= reset;
reset: if( x==1b1 ) current <= got1;
else current <= reset;
got1: if( x==1b0 ) current <= got10;
else current <= got1;
got10: if( x==1b1 ) current <= got1;
else current <= reset;
default: current <= reset;
endcase end
Hard-Reset Assertion (Continued)
98
Initial Resetting
............................
............................
assign z = ( current==got10 && x==1b1 ) ? 1b1 :
1b0;
Checks if rst is 1
assert_next
the next
current does not
#(1, 1, 1, 0, 0, then
Err:
Machine
state becomes
reset properly,
0)reset
AN1 (clk, 1b1, rst, (current==reset));
endmodule
Assertion Monitor is
Hard-Reset Assertion (Continued)
always active.
99
Implication
Assertion
Templates
Reset
Sequence
Initial
Resetting
Implication
Valid States
100
Implication
Checks on the specified

clock edge for the antecedent
expression to be true. If it is,
A
useful
assertion
for
then
it checks
for the
checkingexpression
expected to be
consequence
events,
true. If
so, it or
willevents
stay quiet,
implied
by other
otherwise
it willevents
fire.
assert_implication
#( severity_level, properety_type,
instance_name ( clk, reset_n,
antecedent_expr,
consequence_expr )
General Format for assert_implication Assertion Monitor
101
Implication
Checks the output value in the
got10 state while (input
x is 1
module mealy_detector2
x, rst, clk, output z);
// . . .
assert_implication
#(1, 0, Err: Output not asserted, 0)
AI1 (clk, 1b1, (current==got10 && x),
(z==1));
// . . .
Always Active
endmodule
Asserting Implication
102
Valid States
Assertion
Templates
Reset
Sequence
Initial
Resetting
Implication
Valid States
103
Valid States
If the states of the machine
being tested are consecutive
binary numbers
In the sequential circuit testing it

often becomes necessary to check
for the machines valid states and
issue a warning if the machine
enters an invalid state.
assert_no_overflow
#( severity_level, width, min, max,
property_type,
General Format for assert_no_overflow Assertion Monitor
104
Valid States
The assertion fires, if the
Of the four possible states,
Mealy machine ever
it is using only three:
enters, the machines
reset, got1, got10.
invalid
The range
of state.
values the test
expression can take.
module mealy_detector2 (input x, rst, clk, output z);
(Min and Max)
// . . .
assert_no_overflow #(1, 2, 0, 2, 0, Err: Invalid
state, 0)
The size of vector being tested
ANV1 (clk, 1b1, current);
// . . .
endmodule
Checking for Invalid States
105
Text Based Testbenches

Verilog has an extensive set of tasks for reading and writing external
files:
Opening and closing files,
Positioning a pointer in a file,
Writing or appending a file
Reading files
106
Summary
This chapter discussed:
The use of Verilog constructs for developing testbenches
Data generation and response analysis by use of Verilog
How assertion monitors could be used for reducing efforts needed
for response analysis of a unit-under-test.
Developing good testbenches for complex designs requires design
observability given to designers by use of assertions.
107

Chapter 6-Testbench

Uploaded by

Copyright:

Available Formats

Chapter 6-Testbench

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 6-Testbench

Uploaded by

Copyright:

Available Formats

Chapter 6

Component Test and Verification

Component Test and Verification

Component Test and Verification

Combinational Circuit Testing

Combinational Circuit Testing

alu_4bit Module Declaration

Combinational Circuit Testing

alu_4bit cut( a, b, f, oe, y, p, ov, a_gt_b,

local regs and wires to the

Combinational Circuit Testing

Testbench for alu_4bit (Continued)

Combinational Circuit Testing

ALU Simulation Results

Sequential Circuit Testing

Sequential Circuit Testing

Testing sequential circuits involves synchronization of Clock with other

Sequential Circuit Testing

Sequential Circuit Testing

Sequential Circuit Testing

In order to reduce chance

d_in input is assigned a

Sequential Circuit Testing

always @( posedge clk )

101 Moore Detector for Test (Continued)

Basic Data Generation (Continued)

adds another initial block

moore_detector MUT ( x, reset, clock, z );

The first time the flow of

Testbench with $stop Simulation Control

Another testbench for

moore_detector MUT ( x, reset, clock, z );

Limiting Data Sets

Limiting Data Sets

initial #24 reset=1'b0;

Applying Synchronized Data

Applying Synchronized Data

Where several sets of data are to be applied:

Applying Synchronized Data

initial repeat(13) #5 clock=~clock;

Synchronized Display of Results

Synchronized Display of Results

This testbench uses an

its new stable value, the z

This testbench is also usable for

Synchronized Display of Results

This testbench is developed

moore_detector MUT ( x, reset, clock, z );

Synchronized Display of Results

initial forever @(posedge clock) #3 x=$random;

Synchronized Display of Results

Test Results of Testbench of Fig. 6.14

A 1101 Moore detector

always @( posedge clk )

An Interactive Testbench (Continued)

Waveform Resulted by the Interactive Testbench

Random Time Intervals

Random Time Intervals

This testbench uses