14 Testbenches

Component Test
and Verification
Adapted from Z. Navabi

Portions Copyright Z. Navabi, 2006
CSE 467
Verilog Digital System Design
Component Test and Verification

We will examine:
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
CSE 467
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.
CSE 467
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.
CSE 467
Testbench
Testbench
Combinational
Circuit
Testing
CSE 467
Sequential
Circuit
Testing
Combinational Circuit Testing

Testbench
Combinational
Combinational
Circuit
Circuit
Testing
Testing
CSE 467
Sequential
Circuit
Testing

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

CSE 467

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

oe, y, p, ov,
ov, a_gt_b,
a_gt_b,
a_eq_b,
a_eq_b, a_lt_b );
.......................
.......................
This instantiation associates
Testbench for alu_4bit
CSE 467
local regs
regs and wires
wires to the ports
of the alu_4bit module

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

CSE 467

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
CSE 467
10
Sequential Circuit Testing

Testbench
Combinational
Circuit
Testing
CSE 467
Sequential
Sequential
Circuit
Testing
Testing
11
Testing sequential circuits involves synchronization of Clock with other

data inputs.
CSE 467
12

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

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

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

of several inputs changing
at the same time,
we usually use prime numbers
Thefor
initial
block
generates circuit
a
timing
of sequential
d_in data input
positive pulse on rst
that begins at
inputs.
is initialized
13 ns and 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;
d_in and clk
always #11 clk = ~clk;
~clk;
Toggles every 11ns
endmodule
A Testbench for misr (Continued)
CSE 467
15
Testing misr
CSE 467
16
Testbench Techniques
Testbench
Techniques
CSE 467
Test
Data
Simulation
Control
Limiting
Data Sets
Applying
Synchronized Data
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Intervals
Buffered
Data Application
17
module moore_detector (input
(input x, rst,
rst, clk,
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
CSE 467
18
..........................
if ( rst ) current = a;
else case ( current )
a : current = x ? b : a ;
b : current = x ? b : c ;
z output becomes 1
c : current = x ? d : a ;
in state d when
d : current = x ? b : c ;
a sequence of 101
default : current = x;
is detected on x
endcase
assign z = (current==d) ? 1'b1 : 1'b0;
endmodule
101 Moore Detector for Test (Continued)
CSE 467
19
Test Data
Testbench
Techniques
CSE 467
Test
Test
Data
Simulation
Control
Limiting
Data Sets
Applying
Synchronized Data
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Intervals
Buffered
Data Application
20
10
Test Data
module test_moore_detector;
test_moore_detector;
reg x, reset, clock;
wire z;
moore_detector MUT ( x, reset, clock, z );
............................
............................
endmodule
Basic Data Generation
CSE 467
21
Test Data
Initial Block
............................
For initializing the reg variables
............................
initial begin
Four
clock=1'b0; x=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;
x=~x;
endmodule
a signal
on x 101 sequence.
a correct
VariablesGenerates
used in the
left-handwith
a period of
14ns
sides in the
procedural
blocks
Periods
of clock and x can be
are declared as
reg
changed to make this happen
Basic Data Generation (Continued)

CSE 467
22
11
Simulation Control
Testbench
Techniques
CSE 467
Test
Data
Simulation
Simulation
Control
Limiting
Data Sets
Applying
Synchronized Data
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Intervals
Buffered
Data Application
23
Simulation Control
Simulation
Control Tasks
Another testbench
for
are $stop and which
$finish
moore_detector
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

CSE 467
24
12
Simulation Control
wire z;
Another testbench for

moore_detector with
$finish Control Task

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

Testbench
Techniques
CSE 467
Test
Data
Simulation
Control
Limiting
Limiting
Data Sets
Applying
Synchronized Data
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Intervals
Buffered
Data Application
27
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 also
be able to
moore_detector MUT ( x, reset, clock,
z );
stop simulation
from
Cause
clock to toggle
running
indefinitely.
13 times every 5 ns
wire z;

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

Testbench
Techniques
CSE 467
Test
Data
Simulation
Control
Limiting
Data Sets
Applying
Applying
Synchronized Data
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Intervals
Buffered
Data Application
29
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.
CSE 467
30
15

This testbench uses an
event control statement to
synchronize data applied
This
delay
This loop waitstofor
the3ns
x with
the clock.
wire z;
makes it possible to use
positive edge of the

thisit,testbench
for
clock,
a
clock, and 3 ns after
moore_detector uut(
clock,
z
);
uut( x, reset,
simulating
post-synthesis
new random data is
designs as well as
generated for x.
behavioral
descriptions
initial #24 reset=0;
initial repeat(13)
initial forever @(posedge
;
@(posedge clock) #3 x=$random
x=$random;
Testbench
Guarantees
that Delays:
Setup
and
changing of data Hold
and Time
clock do not coincide.
endmodule
Synchronizing Data with Clock
CSE 467
31
Synchronized Display of Results

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

This testbench uses an
event control statement for
synchronized observation
reg x=0,
x=0, reset=1, clock=0;
of
MUT
1ns
after
the outputs
positiveor
edge
wire z;
internal
signals.
of the clock,
when
the circuit
output is supposed to have
moore_detector MUT ( x, reset, clock,
z );
its new stable value, the z
output is displayed using the
initial #24 reset=0;
$displayb task.
initial repeat(13)
;
x=$random;
@(posedge clock) #1 $displayb(z);
$displayb(z);
endmodule
Testbench Displaying Output
CSE 467
This testbench is also usable

for the post-synthesis
simulation of moore_detector
33

reg x=0,
x=0, reset=1, clock=0;
wire z;
This testbench is developed

for observing states of
moore_detector

............................
............................
endmodule
Testbench Displays Design Variables when they change
CSE 467
34
17

Display occurs when an
............................
event occurs on one of the
............................
variables of the Uses
task
tasks$monitor to display
current register
Starts
$monitor task
initial
#24 reset=0;arguments.
Hierarchial
in the
background
initial
repeat(19)
repeat(19) #5 clock=~clock; In binary
Event Based
Naming
$random;
;
x=format
initial $monitor("New
$monitor("New state is %b and occurs
at %t", MUT.current, $time);
$time);
always @(z) $display("Output
$display("Output changes at %t to %b",
With
$time,
, the
z);
$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.
CSE 467
35
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
occurs at
occurs at
occurs at
occurs at
0
50 to 0
50
250
850
950 to 1
950
Test Results of Testbench
CSE 467
36
18
An Interactive Testbench
Testbench
Techniques
CSE 467
Test
Data
Simulation
Control
Limiting
Data Sets
Applying
Synchronized Data
Synchronized
Display of Results
An Interactive
Testbench
Random Time
Intervals
Buffered
Data Application
37
module moore_detector (input
(input x, start, rst,
rst, clk,
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
CSE 467
38
19
if ( rst ) current <= a;
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:
default: current <= a;
endcase
assign z = (current==e);
Output becomes 1 in state e
endmodule
Moore Sequence Detector Detecting 1101 (Continued)
CSE 467
39
reg x=0, start, reset=1, clock=0;
wire z;
moore_detector MUT ( x, start, reset, clock, z );
............................
............................
............................
endmodule
CSE 467
40
20
To get the machine started
initial begin
#24 reset=1'b0; start=1'b1;
wait(z
==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)
repeat(3) begin
Repeats the process of
#11 start=1'b0;
starting the machine and
waiting for z to become 1
#13 start=1'b1;
3 more times
wait(z
==1'b1);
wait(z==1'b1);
end
After 50 ns simulation is stopped
#50 $stop;
$stop;
end
An Interactive Testbench (Continued)

CSE 467
41
............................
............................
............................
always blocks to generate
always #7 x=$random
;
x=$random;
clock and x input
endmodule
An Interactive Testbench (Continued)
CSE 467
42
21
Waveform Resulted by the Interactive Testbench
CSE 467
43
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
CSE 467
44
22
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;
$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
;
x=$random;
endmodule
Interactive Testbench Using Display Tasks (Continued)
CSE 467
45
Random Time Intervals

Testbench
Techniques
CSE 467
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
46
23

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
CSE 467
47

Nonblocking assignments
cause intra-assignment
delay values to be regarded
as absolute timing values
initial begin:running
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;
$finish;
end
Testbench using Random Time Intervals (Continued)
CSE 467
48
24

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

Testbench
Techniques
CSE 467
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
50
25

reg x=0,
x=0, rst,
rst, start, clk=0;
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,

rst, clk,
clk, z );
............................
............................
endmodule
Testbench Applying Buffered Data
CSE 467
51

We are sure a correct
sequence is applied to
............................
our MUT and can
initial buffer = 19'b0001101101111001001;
more easily check for
initial begin
expected results.
19-bit buffer is initialized with test data
rst=1'b1;
rst=1'b1; start=1'b0;
Start and stop control of the
#29 rst=1'b0;
rst=1'b0;
machine
Each bit of the buffer isstate
shifted
out
#29 start=1'b1;
onto the x input of MUT
#500 $stop;
$stop;
1ns after the positive edge of clock
end
always @(posedge
};
@(posedge clk)
clk) #1 {x, buffer} = {buffer,x
{buffer,x};
always #5 clk = ~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
CSE 467
52
26
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.
CSE 467
53
Assertion Verification
Assertion
Verification
CSE 467
Assertion
Verification
Benefits
Open
Verification
Library
Using
Assertion
Monitors
Assertion
Templates
54
27
Assertion Verification
Unlike simulation, here in-code monitors issue a message if something
happens that is not expected.
In Verilog,
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.
CSE 467
55
Assertion Verification Benefits

Assertion
Verification
CSE 467
Assertion
Assertion
Verification
Benefits
Benefits
Open
Verification
Library
Using
Assertion
Monitors
Assertion
Templates
56
28
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.
CSE 467
57
Open Verification Library

Assertion
Verification
CSE 467
Assertion
Verification
Benefits
Open
Open
Verification
Verification
Library
Library
Using
Assertion
Monitors
Assertion
Templates
58
29
Assertions
CSE 467
59

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
)
#(static-parameters)
Any Unique name is
allowed
instance-name
instance-name
(dynamic-arguments);
Assertion Module Instantiation
CSE 467
Reference and monitor signals

and other dynamic arguments
60
30
Using Assertion Monitors

Assertion
Verification
CSE 467
Assertion
Verification
Benefits
Open
Verification
Library
Using
Using
Assertion
Assertion
Monitors
Assertion
Templates
61
Using Assertion Monitors

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

between 0 and 9
module BCD_Counter (input

(input rst,
rst, clk,
clk,
output reg [3:0] cnt);
cnt);
always @(posedge
@(posedge clk)
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
Count, 0)
AA1 (clk
, 1'b1, (cnt
(clk,
(cnt >= 0) && (cnt
(cnt <= 9));
Indicates that the assertion is
The test expression:

The monitor checks that on
every rising edge of clk,
clk, cnt
must be between 0 and 9
endmodule
to be monitored at all times
BCD with assert_always

CSE 467
65
assert_always
module BCD_Counter_Tester;
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

CSE 467
66
33
assert_change
Assertion
Monitors
assert_always
assert_change
assert_one_hot
assert_
cycle_sequence
assert_next
CSE 467
67
assert_change
Verifies that within a
given number of clocks
after the start event, the
test expression changes.
assert_change
#( severity_level,
severity_level, width, num_cks,
num_cks,
action_on_new_start,
action_on_new_start, property_type,
property_type,
msg,
clk, reset_n,
reset_n, start_event,
start_event,
test_expr )
General Format for assert_change Assertion Monitor
CSE 467
68
34
assert_change
A shift register that walks
a 1 with every clock.
module Walking_One (input
(input rst,
rst, clk,
clk, output reg [7:0] wo);
wo);
always @(negedge
@(negedge clk)
clk) begin
if (rst
) wo <= 8'b10000000;
(rst)
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
changing, 0)
AC1 (~clk
, ~rst
, (rst
==0), wo[0]);
(~clk,
~rst,
(rst==0),
assert_one_hot #(1, 8, 0, "Err: Multiple active
bits
bits, 0)
AOH (~clk
, ~rst
, wo);
(~clk,
~rst,
wo);
endmodule
Walking One Circuit with Assertions

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

CSE 467
Test Expression
70
35
assert_change
module Walking_One_Tester ();
reg rst=0,
rst=0, clk=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,
(rst,
clk, walking);
initial repeat (223) #7 clk=
;
clk= ~clk
~clk;
initial repeat (15) #109 rst=
;
rst= ~rst
~rst;
endmodule
Walking_One Testbench
CSE 467
When rst becomes 1,

the falling edge of the
clock puts a 1 into wo[7]
71
When rst becomes 0, this

assert_change
1 starts walking, it takes 7
clock edges for this 1 to
walk to bit 0 of wo.
wo.
Signals connected to
Walking-One
Test Results
wo[7] to wo[0]
CSE 467
72
36
assert_one_hot
Assertion
Monitors
assert_always
assert_change
assert_one_hot
assert_
cycle_sequence
assert_next
CSE 467
73
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,
severity_level, width, property_type,
property_type,
msg,
clk, reset_n,
General Format for assert_one_hot Assertion Monitor
CSE 467
74
37
assert_one_hot
module Walking_One (input
(input rst,
rst, clk,
clk, output reg [7:0] wo);
wo);
always @(negedge
@(negedge clk)
clk) begin
if (rst
) wo <= 8'b10000000;
(rst)
else wo <= {wo[0], wo[7:1]};
end
changing
changing, 0)
AC1 (~clk
, ~rst
, (rst
==0), wo[0]);
(~clk,
~rst,
(rst==0),
bits
bits, 0)
AOH (~clk
, ~rst
, wo);
(~clk,
~rst,
wo);
endmodule

CSE 467
75
assert_one_hot
............................
............................
always @(negedge
@(negedge clk)
clk) begin
if (rst
) wo <= 8'b10000000;
(rst)
else wo <= {wo[0], wo[7:1]};
end
Test expression width
............................
bits
bits, 0)Test expression
AOH (~clk
, ~rst
, wo);
(~clk,
~rst,
wo);
CSE 467
Makes the checking

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

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

@(posedge clk)
clk) old <= q;
assert_one_hot #(1, 4, 0, "Err: Not Gray
Gray, 0)
AOH (~clk
, ~rst
, (old ^ q));
(~clk,
~rst,
endmodule
Gray Code Counter (Continued)
CSE 467
78
39
assert_cycle_sequence
Assertion
Monitors
assert_always
assert_change
assert_one_hot
assert_
cycle_sequence
assert_next
CSE 467
79
Checks for a sequence of
events in a given number
of clocks.
#( severity_level,
severity_level, num_cks,
num_cks,
necessary_condition,
necessary_condition,
property_type,
property_type,
msg,
clk, reset_n,
reset_n, event_sequence)
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 circuit
circuits reset input.
CSE 467
80
40
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
1
a=0
0
1
0
0
10
b=1
0
d=3
0
0
c=2
0
A Sequencing State Machine
CSE 467
81
module Sequencing_Machine (input
(input x, start, rst,
rst, clk,
clk,
output z );
reg [2:0] current;
............................
............................
Verilog Code of Sequencing_Machine
CSE 467
82
41
............................
if ( rst ) current <= a;
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:
default: current <= a;
endcase
Verilog Code of Sequencing_Machine (Continued)
CSE 467
83
monitor is setup
assert_cycle_sequencetoThis
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 areclock
reached
assign
(current==e);
Number
of stateszin =
sequence
machine
into state a.
assert_cycle_sequence in the specified sequence.
#(1, 3, 0, 0, "Err: State sequence not

followed
followed, 0)
ACS (clk
, ~rst
, {(current==d),
(clk,
~rst,
(current==e), (current==a)});
assert_next #(1, 2, 1, 0, 0, "Err: Output state
The reached
sequence of
states
not
,
0) to verify
reached
AN1 (clk
, ~rst
, (current==c && x==0),
(clk,
~rst,
(z==1));
endmodule
CSE 467
84
42
If the machine enters state

4 (e
(e ), then state 0 (a
(a ) is
entered.
Sequencing_Machine State Transitions
CSE 467
85
assert_next
Assertion
Monitors
assert_always
assert_change
assert_one_hot
assert_
cycle_sequence
assert_next
CSE 467
86
43
assert_next
Verifies that starting and
an ending events occur
with a specified number
of clocks in between.
assert_next
#( severity_level,
severity_level, num_cks,
num_cks,
check_overlapping,
check_overlapping,
check_missing_start,
check_missing_start, property_type,
property_type,
msg,
clk, reset_n,
reset_n, start_event,
start_event,
test_expr)
test_expr)
General Format for assert_next Assertion Monitor
CSE 467
87
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
followed
,
0)
followed
Number of clock
ACS (clk
clk,
, the
~rst
, {(current==d),
(
~rst,
cycles
between
events
(current==e), (current==a)});
assert_next #(1, 2, 1, 0, 0, "Err: Output state
not reached
reached, 0)
AN1 (clk
, ~rst
, (current==c && x==0),
(clk,
~rst,
(z==1));
Start Expression
endmodule
Test Expression

CSE 467
88
44
Assertion Templates
Assertion
Verification
CSE 467
Assertion
Verification
Benefits
Open
Verification
Library
Using
Assertion
Monitors
Assertion
Assertion
Templates
Templates
89
Assertion Templates
Hardware features designers may need to verify, and how assertions

can be used for their verification
CSE 467
90
45
Assertion Templates
Assertion
Templates
CSE 467
Reset
Sequence
Initial
Resetting
Implication
Valid States
91
Reset Sequence
Assertion
Templates
CSE 467
Reset
Reset
Sequence
Sequence
Initial
Resetting
Implication
Valid States
92
46
Reset Sequence
Often controllers have a
resetting sequence that
with certain sequence of
module Sequencing_Machine (input
start,
rst,
clk,
(input x,inputs,
rst, ends
clk,
the machine
Verifies output
that if in three
z state
); it is in.
of what
consecutive clocks, x is 0,
in the fourth clock the
// . . .
current state of the
machine becomes a.
#(1, 4, 0, 0, "Err:Resetting
"Err:Resetting does not occur")
ACS2 (clk
, ~rst
, {(x==0), (x==0), (x==0),
(clk,
~rst,
(current==a)});
// . . .
endmodule
Assertion Reset Sequence
CSE 467
93
Initial Resetting
Assertion
Templates
CSE 467
Reset
Sequence
Initial
Resetting
Resetting
Implication
Valid States
94
47
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
(input x, rst,
rst, clk,
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
CSE 467
95
Initial Resetting
............................
always @( posedge clk ) begin
if (rst)
rst) current <= reset;
reset: if(
if( x==1
x==1b1 ) current <= got1;
else current <= reset;
got1: if(
if( x==1
else current <= got1;
got10: if(
if( x==1
else current <= reset;
default:
default: current <= reset;
endcase end
Hard-Reset Assertion (Continued)
CSE 467
96
48
Initial Resetting
............................
............................
assign z = ( current==got10 && x==1
x==1b1 ) ? 1
1b1 :
1
1b0;
Checks if rst is 1
assert_next
then
the next
current does not
#(1, 1, 1, 0, 0, Err:
Machine
state
becomes
reset properly
properly, 0)reset
AN1 (clk
, 1
(clk,
1b1, rst,
rst, (current==reset));
endmodule
Assertion Monitor is
Hard-Reset Assertion
(Continued)
always active.
CSE 467
97
Implication
Assertion
Templates
CSE 467
Reset
Sequence
Initial
Resetting
Implication
Valid States
98
49
on the specified
ImplicationclockChecks
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,
or events
true. If
so, it will
stay quiet,
implied
by
otherwise other
it willevents
fire.
assert_implication
#( severity_level,
severity_level, properety_type,
properety_type,
msg,
clk, reset_n,
reset_n,
antecedent_expr,
antecedent_expr,
consequence_expr )
General Format for assert_implication Assertion Monitor
CSE 467
99
Implication
Checks the output value in the
got10 state while x(input
1
module mealy_detector2
input
x, rst,
(is
rst, clk,
clk, output z);
// . . .
assert_implication
#(1, 0, Err: Output not asserted
asserted, 0)
AI1 (clk
, 1
(clk,
1b1, (current==got10 && x),
(z==1));
// . . .
Always Active
endmodule
Asserting Implication
CSE 467
100
50
Valid States
Assertion
Templates
CSE 467
Reset
Sequence
Initial
Resetting
Implication
Valid States
101
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 machine
machines valid states and
issue a warning if the machine
enters an invalid state.
assert_no_overflow
#( severity_level,
severity_level, width, min, max,
property_type,
property_type,
msg,
clk, reset_n,
General Format for assert_no_overflow Assertion Monitor
CSE 467
102
51
Valid States
The assertion fires, if the
Mealy machine ever
enters, the machine
machines
invalid
state. the test
The range
of values
expression can take.
module mealy_detector2 (input
(input x, rst,
rst, clk,
clk, output z);
(Min and Max)
Of the four possible states,
it is using only three:
reset,
reset, got1,
got1, got10.
got10.
// . . .
assert_no_overflow #(1, 2, 0, 2, 0, Err: Invalid
state
state, 0)
The size of vector being tested
ANV1 (clk
, 1
(clk,
1b1, current);
// . . .
endmodule
Checking for Invalid States
CSE 467
103
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
CSE 467
104
52
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.
CSE 467
105
53

14 Testbenches

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

14 Testbenches

Uploaded by

Copyright:

Available Formats

Component Test

Adapted from Z. Navabi

Verilog Digital System Design

Component Test and Verification

Verilog Digital System Design

Verilog Digital System Design

Verilog Digital System Design

Verilog Digital System Design

Combinational Circuit Testing

Verilog Digital System Design

Combinational Circuit Testing

alu_4bit Module Declaration

Verilog Digital System Design

Combinational Circuit Testing

alu_4bit cut( a, b, f, oe,

Combinational Circuit Testing

Testbench for alu_4bit (Continued)

Verilog Digital System Design

Combinational Circuit Testing

ALU Simulation Results

Verilog Digital System Design

Sequential Circuit Testing

Verilog Digital System Design

Sequential Circuit Testing

Testing sequential circuits involves synchronization of Clock with other

Verilog Digital System Design

Sequential Circuit Testing

Sequential Circuit Testing

Verilog Digital System Design

Sequential Circuit Testing

In order to reduce chance

d_in input is assigned

Sequential Circuit Testing

Verilog Digital System Design

Verilog Digital System Design

always @( posedge clk )

Verilog Digital System Design

Verilog Digital System Design

Verilog Digital System Design

Basic Data Generation (Continued)

Verilog Digital System Design

Verilog Digital System Design

adds another initial block

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

The first time the flow of

Testbench with $stop Simulation Control

Verilog Digital System Design

Another testbench for

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

Verilog Digital System Design

Verilog Digital System Design

Limiting Data Sets

Verilog Digital System Design

Limiting Data Sets

initial #24 reset=1'b0;

Verilog Digital System Design

Applying Synchronized Data

Verilog Digital System Design

Applying Synchronized Data

Where several sets of data are to be applied:

Verilog Digital System Design

Applying Synchronized Data

positive edge of the