Thiet Ke Vi Mach So Nang Cao Truong Quang Vinh Asic&Ip Ch4 p1 (Cuuduongthancong - Com)

ĐẠI HỌC QUỐC GIA TP.
HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC BÁCH KHOA
KHOA ĐIỆN-ĐIỆN TỬ
BỘ MÔN KỸ THUẬT ĐIỆN TỬ
om
.c
ng
ASIC CHIP AND IP CORE DESIGN
co
an
th
ng
Chapter 4: Verification Process (Part 1)
o
du
4.1 Test environment

u
4.2 Testbench design

cu
4.3 Formal verification

4.4 Boundary-scan test
1 CuuDuongThanCong.com https://fb.com/tailieudientucntt
4.1 Test Environment
om
Testbench
Clock
.c
Generation
ng
Input Response Verification
co
Initialization Stimuli Assessment Utility & Synch’n
an
th
ng
Testbench to Design Interface
o
du
u
cu
Design Under
Verification
Bộ môn Kỹ Thuật Điện Tử

CuuDuongThanCong.com https://fb.com/tailieudientucntt
2
Test Environment: Examples
• Compute Remainder of CRC-8
om
– Input vector % (10000111)
.c
Clock
ng
Input
Q0 D
co
Q1 D
Q7 D Q6 D Q5 D Q4 D Q3 D Q2 D FF
FF
FF FF FF FF FF FF
an
th
ng
 Instantialtion:
o
du
u
CRC8 DUV (.IN(in), .CLK(clk), .Q0(q0), … , .Q7(q7));

cu
Bộ môn Kỹ Thuật Điện Tử CuuDuongThanCong.com https://fb.com/tailieudientucntt

3
– Description of design under verification and input stimuli:
om
• Need to apply a bit stream:
.c
• Store bits in an array and apply the array.
ng
initial i = size_of_input;
co
always @(posedge clk) begin
an
if (i != 0) begin
th
ng in <= input_array[i];
i <= i – 1;
end
o
du
end
 Response assessment:
u
cu
remainder = input_array % 8’b10000111;

if (remainder != {q7, q6, q5, q4, q3, q2, q1,
q0})
print_error();

4
– FF initialization:
om
initial begin
.c
DUV.Q0 = 1’b0;
ng
DUV.Q1 = 1’b0;
co
…
DUV.Q7 = 1’b0;
an
 Clock generation: th
o ng
du
always clk = #1 ~clk;

u
cu

5
Utilities for Test Environment
• Software tools
om
– Matlab
.c
– ModelSim
ng
co
– VCS
an
• Languages
th
ng
– VHDL, Verilog, SystemC
o
– Vera, Specman
du
u
– OVM, VMM
cu
– C/C++

6
4.2 Testbench Design
• Design test cases:
om
– Initialization
.c
– Input stimulus generation
ng
– Responses assessment
co
• Approach
an
th
a) Initialize all inputs ng
b) Generate the clock signals
o
c) Send test vectors

du
d) Assess the response signals

u
cu

7
Test case: Example
• Example:
om
– TC1:
.c
• Verify integers add/subtract
• Input vectors chosen to cause corner cases (e.g. overflow)
ng
– TC2:
co
• Verify Boolean operations:
an
• Input vectors: certain bit patterns (e.g. 101010101, 11111111)
• Reusability: th
ng
– Use the same testbench for multiple test cases
o
du
•  To maximize portability, TCs must be separated from testbench,

u
• e.g. read initial values from a file (that contains a TC).

cu

8
a. Initialization
• Initialization:
om
– Assign values to state elements (FFs, memories)
.c
– Although the task of circuitry (at power-on), often done in
ng
testbench.
co
– Reasons:
an
• Initialization circuit has not designed at the time.
th
• Simulation is to run starting from a long time after power-on,
ng
– (e.g. simulating through initialization stage takes too long)
o
du
• Simulation emulates an exception condition (normal operation

never reaches it from its legal initial states).
u
cu
– To gain reusability, initialization code should be

encapsulated inside a procedure.
9
a. Initialization
• Initialization @ time zero:
– Some simulators create a transition (event) from unknown X
om
(uninitialized) to initial value and some others don’t.
.c
 Inconsistent results from simulator to simulator.
ng
–  Initialize at a positive time.
co
– Even safer:
an
• Initialize to X (or ‘U’) at time zero.
th
• Then initialize to init value at a positive time.
ng
task init_later;
input [N:0] value;
o
du
begin
design.usb.xmit.Q = 1’bx;
u
…
cu
#1;
design.usb.xmit.Q = value[0];
…
end
end task

10
b. Clock Generation
• Explicit Method: • Toggle Method:
om
.c
initial clock = 1’b0; initial clock = 1’b0;
always begin always begin
ng
#1 clock = 1’b1; #1 clock = ~clock; // rising
co
#1 clock = 1’b0; #1 clock = ~clock; // falling
#2 clock = 1’b1; #2 clock = ~clock; // rising
an
#2 clock = 1’b0; #2 clock = ~clock; // falling
end end
th
ng
period
o
du
u
cu
clock

11
b. Clock Generation
• Toggle Method:
om
– Difficult to see the value of clock at a given time
.c
• Comments: falling/rising.
ng
– If left uninitialized, doesn’t toggle (starts at x)
co
• A potential bug.
an
th
– Easy to change the phase or initial value.
ng
• Other statements kept intact.
o
du
• Time Unit and Resolution:

u
cu
– During verification, clock period/duty cycle may

change
•  Use parameters (rather than hard coding)
12
b. Clock Generation
• Multiple Clock Systems with a Base Clock:
om
– Clock divider:
.c
initial i = 0;
ng
always @(base_clock)
co
begin
an
i = i % N;
if (i = 0) derived_clock = ~derived_clock;
th
i = i +1; ng
end
o
du
 Clock multiplier:
u
− Note: Synchronized with the base clock.

cu
always @(posedge base_clock)

begin
repeat (2N) clock = #(period)/(2N)) ~clock;
end

13
b. Clock Generation
• Multiple Clock Systems with a Base Clock:
– If the period of the base clock not known, Measure it:
om
.c
initial begin
derived_clock = 1’b0; //assume starting 0
ng
@(posedge base_clock) T1 = $realtime;
@(posedge base_clock) T2 = $realtime;
co
period = T2 – T1;
T1 = T2;
an
->start; // start generating derived_clock
end
th
// continuously measure base block’s period
ng
always @(start)
forever
o
@(posedge base_clock) begin
du
T2 = $realtime;
period = T2 – T1;
u
T1 = T2;
cu
end
//generate derived_clock N times the freq of base_clock

always @(start)
forever derived_clock = #(period/(2N)) ~derived_clock;

14
b. Clock Generation
• If two periods are independent, don’t generate one
om
from the other.
.c
ng
initial clock1 = 1’b0; initial clock1 = 1’b0;
co
always clock1 = #1 always clock1 = #1 ~clock1;
~clock1;
an
initial clock2 = 1’b0;
th
always @(negedge clock1) clock2 = #2
always clock2 = #2 ~clock; ng ~clock;
o
Right Wrong
du
u
cu

15
b. Clock Generation
 Any simulator shows the same waveform but they are
om
different:
− Adding jitter to clock1 must not affect clock2
.c
ng
co
always clock1 = #1 ~clock1;
an
jitter = $random(seed) % RANGE;
th
assign clock1_jittered = (jitter) clock1;
ng
o
du
u
cu

16
b. Clock Synchronization
– When two independent waveforms arrive at the same gate, glitches
om
may be produced:
•  intermittent behavior.
.c
– Independent waveforms should be synchronized before propagation
ng
co
an
th Synch’er
ng
w1
o
w3
du
Synchronized
signal
Synchronizing
u
w2
cu
Signal

17
• Synchronizer:
om
– A latch.
.c
– Uses a signal (synchronizing) to trigger sampling of
ng
another to create a dependency between them.
co
an
•  Removes uncertainty in their relative phase.
th
ng
always @(fast_clock)
o
clock_synchronized <= clock;
du
u
cu
 Some transitions may be missed.

−  The signal with highest frequency is chosen as the synch’ing signal.

18
• Synchronous Method:
om
– Applying vectors to primary inputs synchronously.
.c
Stimuli Memory
ng
input vector
10111011 I/O
co
10111100 memory
an
00001110 I D
Control Data
th
00101101
00001111
ng
11011011
o
00110010
du
10101010
u
cu
Stimulus Design
Clock
Testbench

19
c. Stimulus Generation
– Vectors stored in stimuli memory (read stimuli from file)
om
– triggered by a stimulus clock, memory is read one vector at
.c
a time.
ng
– Stimulus clock must be synchronized with design clock.
co
– Encapsulate the code for applying data in a task (procedure)
an
•  Stimulus application is separated from particular memory or
th
design ng
• Asynchronous Method:
o
du
– Sometimes inputs are to be applied synchronously.

u
• e.g. Handshaking.
cu

20
d. Response Assessment
• Two parts of response assessment:
om
1. Monitoring the design nodes during simulation
2. Comparing the node values with expected values.
.c
ng
• Absence of discrepancy  could have many meanings:
co
– Erroneous nodes were not monitored,
an
– Bugs were not exercised by the input stimuli, 
th
– There are bugs in the “expected” values that masks the
ng
real problem, 
o
du
– The design is indeed free of bugs  

u
cu

21
• Comparison Methods:
om
1. Offline (post processing)
.c
 Node values are dumped out to a file during simulation
ng
 Then the file is processed after the simulation is finished.
co
2. On the fly
an
 Node values are gathered during simulation and are compared with
th
expected values. ng
o
du
u
cu

22
• Offline: Design State Dumping:
om
– In text or VCD (Value change Dump)
.c
• To be viewed by a waveform viewer.
ng
– With dumping  simulation speed: 2x-20x decreased.
co
•  If simulation performance needed, avoid dumping out all nodes.
an
• Must use measures to locate bugs efficiently.
th
o ng
du
u
cu

23
• Measures for efficient bug locating:
om
– Scope:
.c
• Restrict dumping to certain areas where bugs are more likely to
ng
occur.
co
– Interval:
• Turn on dumping only within a time window.
an
th
– Depth: ng
• Dump out only at a specified depth (from the top module).
o
– Sampling:
du
• Sample signals only when they change.

u
• Sample signals with each clock: Not recommended because:

cu
1. Some signal values are not caught.

2. Slow if some signals are not changed over several clocks.

24
• Run-Time Restriction:
om
– Dumping routines should have parameters to turn
.c
on/off dumping.
ng
co
an
$dump_nodes(top.A, depth, dump_flag)
th
o ng
du
Scope: Module A
u
Restrict up to depth depth

cu
E.g. if forbidden state reached

25
• Golden Response:
om
– Visual inspection of signal traces is suitable only
.c
• for a small number of signals.
ng
• when the user knows where to look for clues (i.e. scope
co
is narrow).
an
– For large designs, the entire set of dumped traces needs to
examined. th
o ng
•  Manual inspection is not feasible.
du
• Common Method:
u
cu
– Compare with “golden response” automatically.

• Unix “diff” if in text.

26
• Golden Response:
om
– Can be generated directly.
.c
– Or by a different model of the design
ng
• e.g. non-synthesizable higher level model or a C/C++ model.
co
– If different responses 
an
• bugs in design,
th
• bugs in golden response.
o ng
du
u
cu

27
Design testbench in Verilog
• Initialization initial begin
om
clk = 0;
rst = 0;
.c
end
• Stimulus generation:
ng
co
#T1 rst = 1;
#T2 rst = 0;
an
th
• Clock generation
ng
always #T clk = ~clk;
o
du
• Response assessment
u
if (expected != product)
cu
begin // alert component

$display (“ERROR: incorrect product, result = %d, …);
$finish;
end

28
Some useful commands:
om
• $display(“..”, arg2, arg3, ..); → much like printf(), displays
.c
formatted string in std output when encountered
ng
• $monitor(“..”, arg2, arg3, ..); → like $display(), but .. displays
co
string each time any of arg2, arg3, .. Changes
an
• $stop; → suspends sim when encountered
th
• $finish; → finishes sim when encountered
ng
• $fopen(“filename”); → returns file descriptor (integer); then,
o
du
you can use $fdisplay(fd, “..”, arg2, arg3, ..); or $fmonitor(fd, “..”,
arg2, arg3, ..); to write to file
u
cu
• $fclose(fd); → closes file

• $random(seed); → returns random integer; give her an integer
as a seed
29
• $display & $monitor string format
om
.c
ng
co
an
th
o ng
du
u
cu

30
Class Assignment
1. Write a testbench for the following designs:
om
a) Multiplexer 8 to 1
.c
b) Signed 8-bit Multiplier
ng
co
c) 8-bit FIFO
an
Requirements:
th
ng
– Generate stimulus inputs
o
Describe golden response for each design

du
–
u
– Assess the response

cu
– Display test results

– Write a report file.
31

Thiet Ke Vi Mach So Nang Cao Truong Quang Vinh Asic&Ip Ch4 p1 (Cuuduongthancong - Com)

Uploaded by

Copyright:

Available Formats

You might also like

Thiet Ke Vi Mach So Nang Cao Truong Quang Vinh Asic&Ip Ch4 p1 (Cuuduongthancong - Com)

Uploaded by

Document Information

Original Description:

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

Thiet Ke Vi Mach So Nang Cao Truong Quang Vinh Asic&Ip Ch4 p1 (Cuuduongthancong - Com)

Uploaded by

Copyright:

Available Formats

ĐẠI HỌC QUỐC GIA TP.

4.1 Test environment

4.2 Testbench design

4.3 Formal verification

Bộ môn Kỹ Thuật Điện Tử

CRC8 DUV (.IN(in), .CLK(clk), .Q0(q0), … , .Q7(q7));

Bộ môn Kỹ Thuật Điện Tử CuuDuongThanCong.com https://fb.com/tailieudientucntt

remainder = input_array % 8’b10000111;

Bộ môn Kỹ Thuật Điện Tử

always clk = #1 ~clk;

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

c) Send test vectors

d) Assess the response signals

Bộ môn Kỹ Thuật Điện Tử

•  To maximize portability, TCs must be separated from testbench,

• e.g. read initial values from a file (that contains a TC).

Bộ môn Kỹ Thuật Điện Tử

• Simulation emulates an exception condition (normal operation

– To gain reusability, initialization code should be

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

• Time Unit and Resolution:

– During verification, clock period/duty cycle may

− Note: Synchronized with the base clock.

always @(posedge base_clock)

Bộ môn Kỹ Thuật Điện Tử

//generate derived_clock N times the freq of base_clock

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

 Some transitions may be missed.

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

– Sometimes inputs are to be applied synchronously.

Bộ môn Kỹ Thuật Điện Tử

– The design is indeed free of bugs  

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

• Sample signals only when they change.

• Sample signals with each clock: Not recommended because:

1. Some signal values are not caught.

Bộ môn Kỹ Thuật Điện Tử

Restrict up to depth depth

E.g. if forbidden state reached

Bộ môn Kỹ Thuật Điện Tử

– Compare with “golden response” automatically.

Bộ môn Kỹ Thuật Điện Tử

Bộ môn Kỹ Thuật Điện Tử

begin // alert component

Bộ môn Kỹ Thuật Điện Tử

• $fclose(fd); → closes file

Bộ môn Kỹ Thuật Điện Tử

Describe golden response for each design

– Assess the response