Unit 5

Component Test
and Verification

Modified from Prof. Navabi’s Lectures

1
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
Component Test and Verification
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

3
Component Test and Verification

 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

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

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

6
 Testbench

Testbench

Combinational Sequential
Circuit Circuit
Testing Testing

7
Combinational Circuit Testing

Testbench

Combinational
Combinational Sequential
Circuit
Circuit Circuit
Testing
Testing Testing

8
 Combinational 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;
output [3:0] y; Data Output
output p, ov, a_gt_b, a_eq_b, a_lt_b;
// . . . Compare Outputs
Parity
endmodule Overflow
Output Output
 alu_4bit Module Declaration

9
 Combinational Circuit Testing
module test_alu_4bit;
reg [3:0] a=4'b1011, b=4'b0110; Variables
connecting to
reg [1:0] f=2'b00; Inputs
reg oe=1;
wire [3:0] y;
Variables
wire p, ov, a_gt_b, a_eq_b, a_lt_b; 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
local regs and wires to the
 Testbench for alu_4bit ports of the alu_4bit module

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

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

 ALU Simulation Results

12
Sequential Circuit Testing

Testbench

Combinational Sequential
Sequential
Circuit Circuit
Circuit
Testing Testing
Testing

13
 Sequential Circuit Testing

 Testing sequential circuits involves synchronization of Clock with other

data inputs.

14
 Sequential Circuit Testing
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
always @( posedge clk ) data and existing misr register
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
 Sequential Circuit Testing

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
 Sequential Circuit Testing
The timing is so chosen to
In order to reduce chance
cover at least one positive
.......................... of several inputs changing
clock edge
initial begin at the same time,
#13 rst=1'b1; we usually use prime numbers
The initial timing
block generates a positive
#19 d_in=4'b1000; d_in data for
input of sequential circuit
pulse on rst that begins at
inputs. 13 ns and
#31 rst=0'b0; is initialized ends at 63 ns.
to 4’b1000
#330 $finish;
end d_in input is assigned a
new value
every 37 ns.
always #37 d_in = d_in + 3; Generate data on
always #11 clk = ~clk; Togglesd_in
everyand clk
11ns
endmodule

 A Testbench for misr (Continued)

17
 Sequential Circuit Testing

 Testing misr

18
 Testbench Techniques
Testbench
Techniques

Test Simulation
Data Control

Limiting Applying
Data Sets Synchronized Data

Synchronized An Interactive
Display of Results Testbench

Random Time Buffered

Intervals Data Application
19
 Testbench Techniques
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
always @( posedge clk )
if ( rst ) current <= a;
..........................
..........................
endmodule

 101 Moore Detector for Test

20
 Testbench Techniques
..........................
if ( rst ) current = a;
else case ( current )
a : current <= x ? b : a ;
b : current <= x ? b : c ;
c : current <= x ? d : a ; z output becomes 1
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)

21
 Test Data
Testbench
Techniques

Test Simulation
Data Control

Limiting Applying
Data Sets Synchronized Data

Synchronized An Interactive
Display of Results Testbench

Random Time Buffered

Intervals 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
clock=1'b0; x=1'b0; reset=1'b1; Four
end Procedural Blocks
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
always #7 x=~x; our machine for
Generates
Variables used inathe
signala on x with101 sequence.
correct
left-hand-
endmodule sides in theaprocedural
period of 14ns
blocks
reg of clock and x can be
Periods
are declared as
changed to make this happen
 Basic Data Generation (Continued)

24
 Simulation Control
Testbench
Techniques

Test Simulation
Simulation
Data Control

Limiting Applying
Data Sets Synchronized Data

Synchronized An Interactive
Display of Results Testbench

Random Time Buffered

Intervals Data Application
25
 Simulation Control
Simulation Control Tasks
Another testbench for
are $stop and $finish
moore_detector which
module test_moore_detector;
adds another initial block
reg x=0, reset=1, clock=0;
that stops the simulation
wire z; at 189 ns.

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

The first time the flow of

initial #24 reset=1'b0;
a procedural block
always #5 clock=~clock;
reaches $stop at 189 ns,
always #7 x=~x; simulation stops.
initial #189 $stop;
A stopped simulation
endmodule
can be resumed.
 Testbench with $stop Simulation Control

26
 Simulation Control
Another testbench for
moore_detector with
$finish Control Task
module test_moore_detector;
reg x=0, reset=1, clock=0;
wire z;

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

............................
............................
endmodule

 Testbench with $finish Simulation Control

27
 Simulation Control
This testbench combines
the initial blocks of
deactivating reset and
............................
simulation control into
............................
initial begin one initial block.

#24 reset=1'b0;
#165 $finish; Simulation terminates at 165 ns.
end
always #5 clock=~clock; A finished simulation
cannot be resumed.
always #7 x=~x;
endmodule

 Testbench with $finish Simulation Control (Continued)

28
 Limiting Data Sets
Testbench
Techniques

Test Simulation
Data Control

Limiting
Limiting Applying
Data Sets Synchronized Data

Synchronized An Interactive
Display of Results Testbench

Random Time Buffered

Intervals Data Application
29
 Limiting Data Sets
Instead of setting
module test_moore_detector; simulation time limit,
reg x=0, reset=1, clock=0; a testbench can put a limit
wire z; on the number of data
put on inputs of a MUT.
This will z
moore_detector MUT ( x, reset, clock, also);
be able to
stop simulation
Cause from
clock to toggle
running
13 timesindefinitely.
every 5 ns
initial #24 reset=1'b0;
initial repeat(13) #5 clock=~clock;
initial repeat(10) #7 x=$random;
InCause
large xcircuits, random
to receive
Generates random data on the x
endmodule data is more
random datauseful
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 Simulation
Data Control

Limiting Applying
Applying
Data Sets Synchronized Data

Synchronized An Interactive
Display of Results Testbench

Random Time Buffered

Intervals Data Application
31
 Applying Synchronized Data

 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
 Applying Synchronized Data
This testbench uses an
module test_moore_detector; event control statement to
reg x=0, reset=1, clock=0; synchronize data applied
wire z; xThis
This loop waitstofor the3ns
with
delay
the clock.
makes
positive edge it possible to use
of the
this it,
clock, and 3 ns after testbench
a for
moore_detector uut( x, reset, clock, z );
simulating
new random data is post-synthesis
designs as well as
generated for x.
initial #24 reset=0; behavioral descriptions
initial repeat(13) #5 clock=~clock;
initial forever @(posedge clock) #3 x=$random;

Testbench
Guarantees that Delays:
endmodule Setup
changing of and
dataHold
and Time
 Synchronizing Data with Clock clock do not coincide.

33
Synchronized Display of Results
Testbench
Techniques

Test Simulation
Data Control

Limiting Applying
Data Sets Synchronized Data

Synchronized
Synchronized An Interactive
Display of Results Testbench

Random Time Buffered

Intervals Data Application
34
 Synchronized Display of Results
This testbench uses an
module test_moore_detector; event control statement for
reg x=0, reset=1, clock=0; synchronized observation
wire z; 1nsof MUT
after the outputs
positive or
edge
internal
of the clock, signals.
when the circuit
output iszsupposed
moore_detector MUT ( x, reset, clock, ); to have
its new stable value, the z
output is displayed using the
initial #24 reset=0;
$displayb task.
initial repeat(13) #5 clock=~clock;
initial forever @(posedge clock) #3 x=$random;
initial forever @(posedge clock) #1 $displayb(z);

This testbench is also usable for

endmodule the post-synthesis
 Testbench Displaying Output simulation of moore_detector

35
 Synchronized Display of Results
This testbench is developed
module test_moore_detector; for observing states of
reg x=0, reset=1, clock=0; moore_detector
wire z;

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

............................
............................
endmodule

 Testbench Displays Design Variables when they change

36
 Synchronized Display of Results
Display occurs when an
............................
event occurs on one of the
variables of theUses
............................ $monitor to display
task’s
Starts $monitor task current register
initial #24 reset=0;arguments.
in the background
initial repeat(19) #5 clock=~clock; In binary Hierarchial
Event Based Naming
initial forever @(posedge clock) #3 x=$random; format
initial $monitor("New state is %b and occurs
at %t", MUT.current, $time);
always @(z) $display("Output changes at %t to %b",
With z);
$time, the
Sensitive to z time unit current state and z output
endmodule Flow Based
Uses $display to display are displayed when they
 Testbench Displays Designthe
Variables
output when they change (Continued)
receive new values.

37
 Synchronized Display of Results

New state is x and occurs at 0

Output changes at 50 to 0
New state is 0 and occurs at 50
New state is 1 and occurs at 250
New state is 2 and occurs at 850
Output changes at 950 to 1
New state is 3 and occurs at 950

 Test Results of Testbench of Fig. 6.14

38
An Interactive Testbench
Testbench
Techniques

Test Simulation
Data Control

Limiting Applying
Data Sets Synchronized Data

Synchronized An Interactive
Display of Results Testbench

Random Time Buffered

Intervals Data Application
39
 An Interactive Testbench
module moore_detector (input x, start, rst, clk,
output z );
parameter a=0, b=1, c=2, d=3, e=4;

A 1101 Moore detector

reg [2:0] current;
With 5 states

always @( posedge clk )

............................
............................
............................
endmodule
 Moore Sequence Detector Detecting 1101

40
 An Interactive Testbench
if ( rst ) current <= a;
else if ( ~start ) current <= a;
else case ( current ) If start becomes 0
a : current <= x ? b : a ; the machine resets to
b : current <= x ? c : a ; initial state 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
 An Interactive Testbench

module test_moore_detector;
reg x=0, start, reset=1, clock=0;
wire z;

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

............................
............................
............................
endmodule

 An Interactive Testbench

42
 An Interactive Testbench
initial begin To get the machine started
#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
wait(z==1'b1); 3 more times
end
#50 $stop; After 50 ns simulation is stopped
end
 An Interactive Testbench (Continued)
43
 An Interactive Testbench

............................
............................
............................
always #5 clock=~clock;
always blocks to generate
always #7 x=$random;
clock and x input

endmodule

 An Interactive Testbench (Continued)

44
 An Interactive Testbench

 Waveform Resulted by the Interactive Testbench

45
 An Interactive Testbench
module test_moore_detector;
reg x=0, start, reset=1, clock=0;
wire z;

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

initial begin
#24 reset=1'b0; start=1'b1;
end
............................
endmodule

 Interactive Testbench Using Display Tasks

46
 An Interactive Testbench
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
end Waits for all simulation event
after e is detected,
to complete before displaying
always #5 clock=~clock;
z becomes 1 and is displayed
always #7 x=$random;
endmodule
 Interactive Testbench Using Display Tasks (Continued)

47
 Random Time Intervals
Testbench
Techniques

Test Simulation
Data Control

Limiting Applying
Data Sets Synchronized Data

Synchronized An Interactive
Display of Results Testbench

Random Time
Random Time Buffered
Intervals
Intervals Data Application
48
 Random Time Intervals
module test_moore_detector; This testbench uses
random wait times for
reg x, start, reset, clock;
assigning values to x
wire z;

reg [3:0] t;

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

............................
............................
endmodule

 Testbench using Random Time Intervals

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

end
 Testbench using Random Time Intervals (Continued)
50
 Random Time Intervals

............................
This block generates data on
............................
x as long as the $finish
............................
statement is not reached
always #5 clock=~clock;
always begin
t = $random; Generates Random data on t
#(t) x=$random;
end Uses t to delay assignments
of random values to x
endmodule

 Testbench using Random Time Intervals (Continued)

51
Buffered Data Application
Testbench
Techniques

Test Simulation
Data Control

Limiting Applying
Data Sets Synchronized Data

Synchronized An Interactive
Display of Results Testbench

Random Time Buffered

Buffered
Intervals Data Application
Data Application
52
 Buffered Data Application
module test_moore_detector; This testbench uses a
buffer to hold data to
reg x=0, rst, start, clk=0; be applied to the
MUT data input
wire z;
reg [18:0] buffer;

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

............................
............................
endmodule

 Testbench Applying Buffered Data

53
 Buffered Data Application
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;
endmodule As data is shifted, buffer is rotated in
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 Open
Verification Verification
Benefits Library

Using
Assertion
Assertion
Templates
Monitors

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 Open
Verification Verification
Benefits
Benefits Library

Using
Assertion
Assertion
Templates
Monitors

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 Open
Open
Verification Verification
Benefits Library
Library

Using
Assertion
Assertion
Templates
Monitors

60
 Open Verification Library

 Assertions

61
 Open Verification Library
An Assertion is placed
in code like a module
instantiation.
Assertion module name
comes first. Followed by static_parameters
Assert_name like vector size and options

#(static-parameters)
Any Unique name is instance-name
allowed (dynamic-arguments);

Reference and monitor signals and

 Assertion Module Instantiation
other dynamic arguments

62
Using Assertion Monitors
Assertion
Verification

Assertion Open
Verification Verification
Benefits Library

Using
Using
Assertion Assertion
Assertion
Templates
Monitors

63
Using Assertion Monitors
Assertion
Monitors

assert_always assert_change

assert_
assert_one_hot
cycle_sequence

assert_next

64
 assert_always
Assertion
Monitors

assert_always assert_change

assert_
assert_one_hot
cycle_sequence

assert_next

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

endmodule
to be monitored at all times The monitor checks that on
 BCD with assert_always every rising edge of clk, cnt
must be between 0 and 9
67
 assert_always
Even though checking
module BCD_Counter_Tester; simulation results is
reg r, c; done in a semi-automatic
wire [3:0] count; fashion, test data
generation is still done
manually by the designer
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

68
 assert_change
Assertion
Monitors

assert_always assert_change

assert_
assert_one_hot
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,
msg, coverage_level )
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
alwaysthat @(negedge
from the time thatclk) begin
(rst ==
if 0)(rst)
and while wo(~rst),
<= it8'b10000000;
takes at most 7 negative clock
else wo 1 <=
for the {wo[0],
length of wo[7:1]};
the 7 for the number of clocks
edges for wo[0] to change.
end test expression that change is to occur

assert_change #(1, 1, 7, 0, 0, "Err: Bit 0 is not

changing“, 0)
AC1 (~clk, ~rst, (rst==0), wo[0]);
............................
Falling edge of clk Test Expression
 Walking One Circuit with Assertions

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

Walking_One MUT (rst, clk, walking);

initial repeat (223) #7 clk= ~clk;
initial repeat (15) #109 rst= ~rst;
endmodule

 Walking_One Testbench

73
 When rst becomes 1,
assert_change
Whenrst becomes 0, this
1 starts walking, it takes 7
the falling edge of the clock edges for this 1 to
clock puts a 1 into wo[7] 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_
assert_one_hot
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,
msg, coverage_level )
instance_name ( clk, reset_n, test_expr )

 General Format for assert_one_hot Assertion Monitor

76
 assert_one_hot
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

 Walking One Circuit with Assertions

77
 assert_one_hot
............................
............................
always @(negedge clk) begin
if (rst) wo <= 8'b10000000;
else wo <= {wo[0], wo[7:1]};
end
Test expression width
............................
assert_one_hot #(1, 8, 0, "Err: Multiple active
bits“, 0)Test expression
AOH (~clk, ~rst, wo);

 Walking One Circuit with Assertions Makes the checking

active only when rst is 0
78
 assert_one_hot
The mem.dat
module gray_counter (input [3:0] d_in, input file that
clk,
rst, ld, contains
outputconsecutive
reg [3:0]
q); Gray code numbers is
reg [3:0] mem[0:15]; read into mem.
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_
assert_one_hot
cycle_sequence

assert_next

81
 assert_cycle_sequence

Checks for a sequence of

assert_cycle_sequence events in a given number
of clocks.
#( severity_level, num_cks,
necessary_condition,
property_type,
msg, coverage_level )
instance_name ( clk, reset_n, event_sequence)

Like
 General Format for assert_cycle_sequence other assertion
Assertion Monitormonitors, this
monitor has an enabling input that
is usually driven by the inactive level
of a circuit’s reset input.
82
 assert_cycle_sequence
After the reset state,
0
the machine searches for
When 110 is
a=0 110 sequence.
received the next 0
e=4 0
2 clock cycles 1
1 0
take the machine 1

back to state a
1 0 b=1
0
d=3
1
0
0 c=2
0
 A Sequencing State Machine 1

83
 assert_cycle_sequence

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
 assert_cycle_sequence
............................
always @( posedge clk )
if ( rst ) current <= a;
else if ( ~start ) current <= a;
else case ( current )
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
 assert_cycle_sequence This monitor is setup
to check if the machine
reaches
For checking that the states d and then
last state
............................ state e,ifthen the next
of the sequence is reached
assign z = the previous states are clock
(current==e); reachedwill move the
Number of states in sequence
machine into state a.
in the specified sequence.
assert_cycle_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“,
not sequence of states
0) to verify
AN1 (clk, ~rst, (current==c && x==0),
(z==1));
endmodule

 Verilog Code of Sequencing_Machine (Continued)

86
 assert_cycle_sequence

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_
assert_one_hot
cycle_sequence

assert_next

88
 assert_next
Verifies that starting and
an ending events occur
with a specified number
assert_next
of clocks in between.
#( severity_level, num_cks,
check_overlapping,
check_missing_start, property_type,
msg, coverage_level )
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,
assert_cycle_sequence
and the time that z
#(1, 3, 0, 0, "Err: State sequence not 1.
becomes
Numberfollowed“,
of clock 0)
ACS
cycles (clk, ~rst,
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
 Verilog Code of Sequencing_Machine (Continued)

90
Assertion Templates
Assertion
Verification

Assertion Open
Verification Verification
Benefits Library

Using Assertion
Assertion
Assertion
Templates
Templates
Monitors

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 Initial
Sequence Resetting

Implication Valid States

93
 Reset Sequence
Assertion
Templates

Reset
Reset Initial
Sequence 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
the machine clk,
Verifies output
that if in three
z state
); it is in.
of what
parameter a=0, b=1, c=2, consecutive
d=3, e=4; clocks, x is 0,
in the fourth clock the
// . . .
current state of the
machine becomes a.
assert_cycle_sequence
#(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 Initial
Sequence Resetting
Resetting

Implication Valid States

96
 Initial Resetting
For verification of many
A Mealy Machine sequential circuits becomes
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;
else case ( current )
reset: if( x==1’b1 ) current <= got1;
else current <= reset;
got1: if( x==1’b0 ) current <= got10;
else current <= got1;
got10: if( x==1’b1 ) current <= got1;
else current <= reset;
default: current <= reset;
endcase end
 Hard-Reset Assertion (Continued)
98
 Initial Resetting

............................
............................
assign z = ( current==got10 && x==1’b1 ) ? 1’b1 :
1’b0;
assert_next Checks if rst is 1
#(1, 1, 1, 0, 0, then
“Err:the next current does not
Machine
0)reset
state becomes
reset properly”,
AN1 (clk, 1’b1, rst, (current==reset));
endmodule
Assertion Monitor is
 Hard-Reset Assertion (Continued)
always active.

99
 Implication
Assertion
Templates

Reset Initial
Sequence Resetting

Implication Valid States

100
 Implication Checks on the specified
clock edge for the antecedent
expression to be true. If it is,
A useful
then assertion
it checks for
for the
checkingexpression
consequence expected to be
events,
true. If so, it or
willevents
stay quiet,
implied
otherwiseby other
it willevents
fire.
assert_implication
#( severity_level, properety_type,
msg, coverage_level )
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
module mealy_detector2 x is 1 x, rst, clk, output z);
// . . .
assert_implication
#(1, 0, “Err: Output not asserted”, 0)
AI1 (clk, 1’b1, (current==got10 && x),
(z==1));
// . . . Always Active
endmodule

 Asserting Implication

102
 Valid States
Assertion
Templates

Reset Initial
Sequence Resetting

Implication Valid States

103
 Valid States
In the sequential circuit testing it
often becomes necessary to check
If the states of the machine
for the machine’s valid states and
being tested are consecutive
issue a warning if the machine
binary numbers
enters an invalid state.
assert_no_overflow
#( severity_level, width, min, max,
property_type,
msg, coverage_level )
instance_name ( clk, reset_n, test_expr )

 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 machine’s
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, 1’b1, 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