Chapter 6 Testbench

1
Chapter 6
Component Test
and Verification

Modified from Prof. Navabis Lectures

2
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
3
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

4

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

5
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.

6
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.

7
Testbench
Testbench
Combinational
Circuit
Testing
Sequential
Circuit
Testing
8
Combinational Circuit Testing
Testbench
Combinational
Circuit
Testing
Sequential
Circuit
Testing
Combinational
Circuit
Testing
9
module alu_4bit (a, b, f, oe, y, p, ov, a_gt_b,
a_eq_b, a_lt_b);
input [3:0] a, b;
input [1:0] f;
input oe;
output [3:0] y;
output p, ov, a_gt_b, a_eq_b, a_lt_b;
// . . .
endmodule
alu_4bit Module Declaration
Data Inputs
Function Input
Data Output
Compare Outputs
Overflow
Output
Parity
Output
10
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;

alu_4bit cut( a, b, f, oe, y, p, ov, a_gt_b,
a_eq_b, a_lt_b );
.......................
.......................
Testbench for alu_4bit
Variables
connecting to
Inputs
Variables
connecting to
Outputs
This instantiation associates
local regs and wires to the
ports of the alu_4bit module
11
.......................
initial begin
#20 b=4'b1011;
#20 b=4'b1110;
#20 b=4'b1110;
#80 oe=1'b0;
#20 $finish;
end
always #23 f = f +1;

endmodule
Testbench for alu_4bit (Continued)
Application of data to
the b data imput
and oe output-enable
Every 20 ns
A new value is
assigned to b
Initial
Block
Waits
for
80ns

Disables the
ALU Output
by setting oe to 0

After 20ns
the simulation
is finished
Allows
effects of the last
input change to be
shown in
simulation results
Application of data
to the f input.
f is increment by 1
every 23 ns.

The $finish statement
is reached at 160 ns.
At this time all
active procedural blocks
stop and simulation
terminates.
12
ALU Simulation Results
Throughout the
simulation a
remains constant
f changes every 23ns
causing various
ALU functions
to be examined
At 140 ns
oe changes to 0
causing the y output
become Z
13
Sequential Circuit Testing
Testbench
Combinational
Circuit
Testing
Sequential
Circuit
Testing
Sequential
Circuit
Testing
14

Testing sequential circuits involves synchronization of Clock with other
data inputs.

15
module #(parameter [3:0] poly=0) misr (input clk,rst,
input [3:0] d_in, output reg [3:0] d_out );

always @( posedge clk )
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
The circuit has a poly parameter
that determines its signature and
data compression.
With each clock a new signature
will be calculated with the new
data and existing misr register
data.

16
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 );

...........................
...........................
A Testbench for misr
Specification of the poly parameter

17
..........................
initial begin
#13 rst=1'b1;
#19 d_in=4'b1000;
#31 rst=0'b0;
#330 $finish;
end

always #37 d_in = d_in + 3;
always #11 clk = ~clk;
endmodule
A Testbench for misr (Continued)
The initial block generates a positive
pulse on rst that begins at 13 ns and
ends at 63 ns.
d_in data input
is initialized
to 4b1000
The timing is so chosen to
cover at least one positive
clock edge

Generate data on
d_in and clk
Toggles every 11ns

d_in input is assigned a
new value
every 37 ns.
In order to reduce chance
of several inputs changing
at the same time,
we usually use prime numbers
for timing of sequential circuit
inputs.
18
Testing misr
19
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
Testbench Techniques
20
module moore_detector (input x, rst, clk, output z );

parameter [1:0] a=0, b=1, c=2, d=3;
reg [1:0] current;

if ( rst ) current <= a;
..........................
..........................
endmodule
101 Moore Detector for Test
Synchronous Reset Input
21
..........................
if ( rst ) current = a;
else case ( current )
a : current <= x ? b : a ;
b : current <= x ? b : c ;
c : current <= x ? d : a ;
d : current <= x ? b : c ;
default : current <= x;
endcase
assign z = (current==d) ? 1'b1 : 1'b0;
endmodule
101 Moore Detector for Test (Continued)
z output becomes 1
in state d when
a sequence of 101
is detected on x
22
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
Test
Data
Test Data
23
Test Data
module test_moore_detector;
reg x, reset, clock;
wire z;

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

............................
............................
endmodule
Basic Data Generation

24
............................
............................
initial begin
clock=1'b0; x=1'b0; reset=1'b1;
end
initial #24 reset=1'b0;
always #5 clock=~clock;
always #7 x=~x;

endmodule
Test Data
Basic Data Generation (Continued)

Four
Procedural Blocks
Variables used in the left-hand-
sides in the procedural blocks
are declared as reg
Initial Block
For initializing the reg variables
Generates a signal with a
period of 10ns on clock
Generates a signal on x with
a period of 14ns
The waveform generated on x
may or may not be able to test
our machine for
a correct 101 sequence.
Periods of clock and x can be
changed to make this happen

25
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
Simulation
Control
Simulation Control
26
Simulation Control
reg x=0, reset=1, clock=0;
wire z;


always #7 x=~x;
initial #189 $stop;
endmodule
Testbench with $stop Simulation Control
Another testbench for
moore_detector which
adds another initial block
that stops the simulation
at 189 ns.
The first time the flow of
a procedural block
reaches $stop at 189 ns,
simulation stops.
A stopped simulation
can be resumed.
Simulation Control Tasks
are $stop and $finish
27
Simulation Control
wire z;


............................
............................
endmodule
Testbench with $finish Simulation Control
Another testbench for
moore_detector with
$finish Control Task
28
Simulation Control
............................
............................
initial begin
#24 reset=1'b0;
#165 $finish;
end
always #7 x=~x;
endmodule
Testbench with $finish Simulation Control (Continued)
This testbench combines
the initial blocks of
deactivating reset and
simulation control into
one initial block.
Simulation terminates at 165 ns.
A finished simulation
cannot be resumed.
29
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
Limiting
Data Sets
Limiting Data Sets
30
Limiting Data Sets
wire z;


initial repeat(13) #5 clock=~clock;
initial repeat(10) #7 x=$random;

endmodule
Testbench Using repeat to Limit 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
stop simulation from
running indefinitely.
Generates random data on the x
input of the circuit.
Cause clock to toggle
13 times every 5 ns
Cause x to receive
random data
10 times every 7 ns
In large circuits, random
data is more useful
for data inputs than for
control signals.

31
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
Applying
Synchronized Data
Applying Synchronized Data
32

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.

33
wire z;

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

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

endmodule
Synchronizing Data with Clock
This testbench uses an
event control statement to
synchronize data applied
to x with the clock.
This loop waits for the
positive edge of the
clock, and 3 ns after it, a
new random data is
generated for x.
Guarantees that
changing of data and
clock do not coincide.
This 3ns delay
makes it possible to use
this testbench for
simulating post-synthesis
designs as well as
behavioral descriptions
Testbench Delays:
Setup and Hold Time
34
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
Synchronized
Display of Results
Synchronized Display of Results
35
wire z;


initial forever @(posedge clock) #1 $displayb(z);

endmodule
Testbench Displaying Output
This testbench uses an
event control statement for
synchronized observation
of MUT outputs or
internal signals.
1ns after the positive edge
of the clock, when the circuit
output is supposed to have
its new stable value, the z
output is displayed using the
$displayb task.
This testbench is also usable for
the post-synthesis
simulation of moore_detector
36
wire z;


............................
............................
endmodule
Testbench Displays Design Variables when they change
This testbench is developed
for observing states of
moore_detector
37
............................
............................
initial $monitor("New state is %b and occurs
at %t", MUT.current, $time);
always @(z) $display("Output changes at %t to %b",
$time, z);
endmodule
Uses $monitor to display
current register
Testbench Displays Design Variables when they change (Continued)
Uses $display to display
the output
current state and z output
are displayed when they
receive new values.
Starts $monitor task
in the background
Event Based
Display occurs when an
event occurs on one of the
variables of the tasks
arguments.
Sensitive to z
Flow Based
Hierarchial
Naming
In binary
format
With the
time unit
38
New state is x and occurs at 0
Output changes at 50 to 0
New state is 0 and occurs at 50
Output changes at 950 to 1
Test Results of Testbench of Fig. 6.14
39
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
An Interactive
Testbench
An Interactive Testbench
40
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;

............................
............................
............................
endmodule
Moore Sequence Detector Detecting 1101
A 1101 Moore detector
With 5 states
41
else if ( ~start ) current <= 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);
endmodule
Moore Sequence Detector Detecting 1101 (Continued)
Output becomes 1 in state e
If start becomes 0
the machine resets to
initial state a
42
reg x=0, start, reset=1, clock=0;
wire z;

moore_detector MUT ( x, start, reset, clock, z );
............................
............................
............................
endmodule

43
initial begin
#24 reset=1'b0; start=1'b1;
wait(z==1'b1);
#11 start=1'b0;
#13 start=1'b1;
repeat(3) begin
#11 start=1'b0;
#13 start=1'b1;
wait(z==1'b1);
end
#50 $stop;
end
An Interactive Testbench (Continued)

To get the machine started
Waits for z to become 1,
After it restarts the machine
After 50 ns simulation is stopped
Repeats the process of
starting the machine and
waiting for z to become 1
3 more times
44
............................
............................
............................
always #7 x=$random;

endmodule
An Interactive Testbench (Continued)

always blocks to generate
clock and x input
45
Waveform Resulted by the Interactive Testbench

46
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
47
............................
always begin : Output_Display
wait(MUT.current == MUT.e);
$display ("$display task shows: The output is
%b", z);
$strobe ("$strobe task shows: The output is
%b", z);
#2 $stop;
end
always #7 x=$random;
endmodule
Interactive Testbench Using Display Tasks (Continued)
Hierarchical Naming
When current becomes e
z is displayed
To observe
output within
a state
Waits for all simulation event
to complete before displaying
Displays as soon as program
flow reaches it
Displays the old value of z
A simulation clock cycle
after e is detected,
z becomes 1 and is displayed
48
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
Random Time
Intervals
Random Time Intervals
49
reg x, start, reset, clock;
wire z;

reg [3:0] t;


............................
............................
endmodule
Testbench using Random Time Intervals
This testbench uses
random wait times for
assigning values to x
50
Waits until the propagation of all
signals be completed
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
@( posedge clock );
@( negedge clock );
end
start=1'b0;
#5;
$finish;
end
Testbench using Random Time Intervals (Continued)
Nonblocking assignments
cause intra-assignment
delay values to be regarded
as absolute timing values
Waits for 13 complete clock
pulses before it de-asserts the
start and finishes the simulation
51
............................
............................
............................
always begin
t = $random;
#(t) x=$random;
end
endmodule
Testbench using Random Time Intervals (Continued)
Generates Random data on t
Uses t to delay assignments
of random values to x
This block generates data on
x as long as the $finish
statement is not reached
52
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
Buffered
Data Application
Buffered Data Application
53

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

moore_detector MUT ( x, start, rst, clk, z );

............................
............................
endmodule
Testbench Applying Buffered Data
This testbench uses a
buffer to hold data to
be applied to the
MUT data input
54
............................
initial buffer = 19'b0001101101111001001;
initial begin
rst=1'b1; start=1'b0;
#29 rst=1'b0;
#29 start=1'b1;
#500 $stop;
end
always @(posedge clk) #1 {x, buffer} = {buffer,x};
always #5 clk = ~clk;
endmodule
Testbench Applying Buffered Data (Continued)
19-bit buffer is initialized with test data
Start and stop control of the state
machine
Each bit of the buffer is shifted out
onto the x input of MUT
1ns after the positive edge of clock
As data is shifted, buffer is rotated in
order for the applied buffered data to
be able to repeat
We are sure a correct
sequence is applied to
our MUT and can
more easily check for
expected results.
55
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.
56
Assertion Verification
Assertion
Verification
Assertion
Verification
Benefits
Open
Verification
Library
Using
Assertion
Monitors
Assertion
Templates
57
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.

58
Assertion Verification Benefits
Assertion
Verification
Assertion
Verification
Benefits
Open
Verification
Library
Using
Assertion
Monitors
Assertion
Templates
Assertion
Verification
Benefits
59
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.
60
Open Verification Library
Assertion
Verification
Assertion
Verification
Benefits
Open
Verification
Library
Using
Assertion
Monitors
Assertion
Templates
Open
Verification
Library
61
Assertions
62
Assertion Module Instantiation
Assert_name
#(static-parameters)
instance-name
(dynamic-arguments);
An Assertion is placed
in code like a module
instantiation.
Assertion module name
comes first.
Followed by static_parameters
like vector size and options
Reference and monitor signals and
other dynamic arguments
Any Unique name is
allowed
63
Using Assertion Monitors
Assertion
Verification
Assertion
Verification
Benefits
Open
Verification
Library
Using
Assertion
Monitors
Assertion
Templates
Using
Assertion
Monitors
64
Using Assertion Monitors
Assertion
Monitors
assert_always assert_change
assert_one_hot
assert_
cycle_sequence
assert_next
65
assert_always
Assertion
Monitors
assert_one_hot
assert_
cycle_sequence
assert_next
assert_always
66
assert_always
General Format for assert_always Assertion Monitor

assert_always
#( severity_level, property_type,
msg, coverage_level )
instance_name ( clk, reset_n, test_expr )

Continuously checks
its test_expr to make
sure it is always
true on the edge of
the
specified clock (clk)
If the test expression fails,
the assertion fires and its
corresponding message
(msg) is displayed
67
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;
end

assert_always #(1, 0, "Err: Non BCD Count, 0)
AA1 (clk, 1'b1, (cnt >= 0) && (cnt <= 9));

endmodule
assert_always
BCD with assert_always
This counter counts
between 0 and 9
The assertion monitor
here uses severity_level 1
The test expression:
The monitor checks that on
every rising edge of clk, cnt
must be between 0 and 9
Indicates that the assertion is
to be monitored at all times
68
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
BCD Counter Testbench
Even though checking
simulation results is
done in a semi-automatic
fashion, test data
generation is still done
manually by the designer
69
assert_change
Assertion
Monitors
assert_one_hot
assert_
cycle_sequence
assert_next
assert_change
70
assert_change
General Format for assert_change Assertion Monitor

assert_change
#( severity_level, width, num_cks,
action_on_new_start, property_type,
instance_name ( clk, reset_n, start_event,
test_expr )
Verifies that within a
given number of clocks
after the start event, the
test expression changes.
71
module Walking_One (input rst, clk, output reg [7:0] wo);
always @(negedge clk) begin
if (rst) wo <= 8'b10000000;
else wo <= {wo[0], wo[7:1]};
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
assert_change
Walking One Circuit with Assertions
A shift register that walks
a 1 with every clock.
A 1 is loaded into the left-most
bit of wo with the rst signal
72
............................
............................
if (rst) wo <= 8'b10000000;
else wo <= {wo[0], wo[7:1]};
end

changing, 0)
AC1 (~clk, ~rst, (rst==0), wo[0]);
............................
1 for the length of the
test expression
7 for the number of clocks
that change is to occur
Falling edge of clk Test Expression
Check that from the time that
(rst == 0) and while (~rst), it
takes at most 7 negative clock
edges for wo[0] to change.
73
assert_change
module Walking_One_Tester ();
reg rst=0, clk=0;
wire [7:0] walking;

Walking_One MUT (rst, clk, walking);
initial repeat (223) #7 clk= ~clk;
initial repeat (15) #109 rst= ~rst;
endmodule
Walking_One Testbench

It is the responsibility of
the testbench developer to
make sure enough data is
applied to cause design
errors to trigger assertion
monitors.

74
assert_change
Walking-One Test Results
Signals connected to
wo[7] to wo[0]
When rst becomes 1,
the falling edge of the
clock puts a 1 into wo[7]
When rst becomes 0, this
1 starts walking, it takes 7
clock edges for this 1 to
walk to bit 0 of wo.
75
assert_one_hot
Assertion
Monitors
assert_one_hot
assert_
cycle_sequence
assert_next
assert_one_hot
76
assert_one_hot
General Format for assert_one_hot Assertion Monitor

assert_one_hot
#( severity_level, width, property_type,
Checks that while the
monitor is active, only
one bit of its n-bit test
expression is 1.
77
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
assert_one_hot
78
assert_one_hot
............................
............................
if (rst) wo <= 8'b10000000;
else wo <= {wo[0], wo[7:1]};
end

............................
bits, 0)
Test expression width
Test expression
Makes the checking
active only when rst is 0
79
assert_one_hot
module gray_counter (input [3:0] d_in, input clk,
rst, ld, output reg [3:0]
q);
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
if( ld )
im_q = d_in;
else
im_q = mem[q]; end
............................
Gray Code Counter
The mem.dat file that
contains consecutive
Gray code numbers is
read into mem.
With each clock, the next
Gray count is looked up
from mem.
80
assert_one_hot
............................
always @( posedge clk ) begin: register
if( rst )
q <= 4'b0000;
else
q <= im_q;
end

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)
In order to check for the
correct Gray code sequencing,
some auxiliary logic have been
used to prepare the test expression
Consecutive Gray code
numbers are only
different in one bit, their
XOR must be one-hot.
81
assert_cycle_sequence
Assertion
Monitors
assert_one_hot
assert_
cycle_sequence
assert_next
assert_
cycle_sequence
82
General Format for assert_cycle_sequence Assertion Monitor
#( severity_level, num_cks,
necessary_condition,
property_type,
instance_name ( clk, reset_n, event_sequence)
Checks for a sequence of
events in a given number
of clocks.
Like other assertion monitors, this
monitor has an enabling input that
is usually driven by the inactive level
of a circuits reset input.
83
b=1
0
d=3
0
c=2
0
a=0
0
0
1
0
1
0
1
0 1
e=4
1
1
0
A Sequencing State Machine
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
84
module Sequencing_Machine (input x, start, rst, clk,
output z );

reg [2:0] current;

............................
............................
Verilog Code of Sequencing_Machine
85
............................
else if ( ~start ) current <= 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)
86
............................
#(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
not reached, 0)
AN1 (clk, ~rst, (current==c && x==0),
(z==1));
endmodule
This monitor is setup
to check if the machine
reaches states d and then
state e, then the next
clock will move the
machine into state a.
Number of states in sequence
For checking that the last state
of the sequence is reached if
the previous states are reached
in the specified sequence.
The sequence of states to verify
87
Sequencing_Machine State Transitions

If the machine enters state
4 (e ), then state 0 (a ) is
entered.
88
assert_next
Assertion
Monitors
assert_one_hot
assert_
cycle_sequence
assert_next
assert_next
89
assert_next
General Format for assert_next Assertion Monitor
assert_next
#( severity_level, num_cks,
check_overlapping,
check_missing_start, property_type,
instance_name ( clk, reset_n, start_event,
test_expr)
Verifies that starting and
an ending events occur
with a specified number
of clocks in between.
90
............................
#(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
not reached, 0)
AN1 (clk, ~rst, (current==c && x==0),
(z==1));
endmodule
assert_next
Verifying that there are
two clock cycles between
the time that current
becomes c while x is 0,
and the time that z
becomes 1.
Start Expression
Test Expression
Number of clock
cycles between the events
91
Assertion Templates
Assertion
Verification
Assertion
Verification
Benefits
Open
Verification
Library
Using
Assertion
Monitors
Assertion
Templates
Assertion
Templates
92
Assertion Templates

Hardware features designers may need to verify, and how assertions
can be used for their verification
93
Assertion
Templates
Reset
Sequence
Initial
Resetting
Implication Valid States
Assertion Templates
94
Assertion
Templates
Reset
Sequence
Initial
Resetting
Reset Sequence
Reset
Sequence
95
Reset Sequence
module Sequencing_Machine (input x, start, rst, clk,
output z );
// . . .

#(1, 4, 0, 0, "Err:Resetting does not occur")
ACS2 (clk, ~rst, {(x==0), (x==0), (x==0),
(current==a)});
// . . .
endmodule
Assertion Reset Sequence
Often controllers have a
resetting sequence that
with certain sequence of
inputs, the machine ends
of what state it is in.
Verifies that if in three
consecutive clocks, x is 0,
in the fourth clock the
current state of the
machine becomes a.
96
Assertion
Templates
Reset
Sequence
Initial
Resetting
Initial
Resetting
Initial Resetting
97
Initial Resetting
module mealy_detector (input x, rst, clk, output z);
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
For verification of many
sequential circuits becomes
necessary to check for resetting the
circuit using a synchronous or
asynchronous reset input.
A Mealy Machine
98
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)
99
Initial Resetting
............................
............................
assign z = ( current==got10 && x==1b1 ) ? 1b1 :
1b0;
assert_next
#(1, 1, 1, 0, 0, Err: Machine does not
reset properly, 0)
AN1 (clk, 1b1, rst, (current==reset));
endmodule
Hard-Reset Assertion (Continued)
Assertion Monitor is
always active.
Checks if rst is 1
then the next current
state becomes reset
100
Assertion
Templates
Reset
Sequence
Initial
Resetting
Implication
Implication
101
Implication
General Format for assert_implication Assertion Monitor
assert_implication
#( severity_level, properety_type,
instance_name ( clk, reset_n,
antecedent_expr,
consequence_expr )
A useful assertion for
checking expected
events, or events
implied by other events
Checks on the specified
clock edge for the antecedent
expression to be true. If it is,
then it checks for the
consequence expression to be
true. If so, it will stay quiet,
otherwise it will fire.
102
Implication
module mealy_detector2 (input x, rst, clk, output z);
// . . .
assert_implication
#(1, 0, Err: Output not asserted, 0)
AI1 (clk, 1b1, (current==got10 && x),
(z==1));
// . . .
endmodule
Asserting Implication
Checks the output value in the
got10 state while x is 1
Always Active
103
Assertion
Templates
Reset
Sequence
Initial
Resetting
Implication Valid States Valid States
Valid States
104
Valid States
General Format for assert_no_overflow Assertion Monitor
assert_no_overflow
#( severity_level, width, min, max,
property_type,
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.
If the states of the machine
being tested are consecutive
binary numbers
105
Valid States
module mealy_detector2 (input x, rst, clk, output z);
// . . .
assert_no_overflow #(1, 2, 0, 2, 0, Err: Invalid
state, 0)
ANV1 (clk, 1b1, current);
// . . .
endmodule
Checking for Invalid States
Of the four possible states,
it is using only three:
reset, got1, got10.
The assertion fires, if the
Mealy machine ever
enters, the machines
invalid state.
The size of vector being tested
The range of values the test
expression can take.
(Min and Max)
106
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

107
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.

Chapter 6 Testbench

Uploaded by

Document Information

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

1

You might also like