Chapter 9_Testbench Verification

CHAPTER 9: TESTBENCH & VERIFICATION

NATIONAL UNIVERSITY OF HO CHI MINH CITY

UNIVERSITY OF INFORMATION TECHNOLOGY

FACULTY OF COMPUTER ENGINEERING

Agenda

Chapter 1: Introduction

Chapter 2: Modules and hierarchical structure

Chapter 3: Fundamental concepts

Chapter 4: Structural modeling (Gate- and switch-level modeling)

Chapter 5: Dataflow modeling (Expression)

Chapter 6: Behavioral modeling

Chapter 7: Tasks and Functions

Chapter 8: Finite state machines

Chapter 9: Testbench and verification

Chapter 10: VHDL introduction

2 UIT Circuit Design with HDL - Chapter 9

UIT Circuit Design with HDL - Chapter 9 3

Simulation & Function Verification

+ Design is simulated and tested for functionality before turning into hardware

+ Do not consider gate, propagation delay, hazards, glitches, race conditions, setup and hold violations, and other related timing issues.

+ Test data are generated by testbench or waveform editor

Design Specification

Behavior Description

Pre-synthesis verification

Synthesis

Timing analyis

Post-synthesis verification

Routing and Placement

Physical layout

Chip Ref. Verilog Digital System Design, Zainalabedin Navabi

Digital design flow (ASIC design flow)

4 Circuit Design with HDL - Chapter 9

Simulation by testbench

5

Digital design flow (ASIC design flow)

Circuit Design with HDL - Chapter 9

Simulation by input waveform

EDA (Electronic Design Automation) flow

Usually good for small design


Qsim in Quartus II

Using Verilog language for testing design module -> Testbench

Testbench is a code for test, not a part of final design.

Timing & display procedures: important in designing testbench


(ModelSim,VCS)

EDA (Electronic Design Automation) flow

Procedure to verify an IP core/Chip


Test plan


Test plan is a documment that may include:

- A test environment

- A test strategy (check list)

- A list of testcases (detail for check list)

- A method for generating testcases (random or a vast

amount of testcases)

- A bugs list

-

Test plan evaluating result method


Observe result model

Self-checking model

Test plan basic components in a testbench


DUT

(Design Under

Test)

Initialization

Input stimuli

Clock generation

Monitor output

Test plan example of a test environment


A test enviroment of the self-checking model

AHB Bus

APB BusAHB/APB

Bridge

Mem

Controller

(DW)

Sdram

smart

model

AHB

Slave

(VIP)

AHB

Master1

(VIP)

M M S S S

framework_top.v

ahb_monitor

APB

Slave

(VIP)

00

00

-20

00

00

00

-10

00

10

00

-20

00

20

00

00

00

-40

00

00

00

40

00

10

00

-40

00

20

00

50

00

00

00

-60

00

00

00

S

ahb_monitor

Master (LCD_ctrl) Slave (LCD_ctrl)

123

Control LCD

COMPARE

Clk & reset_n

gen

tb_LCD_ctrl.v

Self-checking result with a test pass

Test plan Example of a test strategy


Test plan Example of a list of testcases


Testbench - Introduction


Source: http://www.asic-world.com/verilog/task_func1.html#Task

Writing a testbench is as complex as writing the RTL code itself.

These days ASICs are getting more and more complex and thus verifying

these complex ASIC has become a challenge.

Typically 60-70% of time needed for any ASIC is spent on

verification/validation/testing.

Even though the above facts are well known to most ASIC engineers, still

engineers think that there is no glory in verification.

Testbench - Introduction

UIT Circuit Design with HDL - Chapter 9 16 Source: http://www.asic-world.com/verilog/task_func1.html#Task

For writing testbenches it is important to have the design specification of

the Design Under Test (DUT) .

Specs (DUT) need to be understood clearly

A test plan, which basically documents the test bench architecture

The test scenarios (test cases) in detail, needs to be made.

In testbench, a dummy template which basically declares inputs/inouts to

DUT as reg and outputs from DUT as wire

Note: there is no port list for the test bench.

Testbench - Example

17 Circuit Design with HDL - Chapter 9

18

Structure of a testbench A test bench is a program which can give arbitrary inputs to Design Under Test (DUT) and observe their outputs.

DUT Provide inputs

Observer Outputs

module testbench;

reg [7:0] dat, declaration of signals

Connection of DUT

The description of the clock

initial begin

.

end

Test case;

endmodule

A description of testbench in Verilog-HDL

Circuit Design with HDL - Chapter 9

Structure of testbench (cont.) 2 styles


Stimulus and Design block instantiated in a Dummy top-level module

Style 1

Stimulus block instantiates Design block

Style 2 (usually used)

Structure of testbench (cont.) Style 1


Stimulus and Design block instantiated in a Dummy top-level module

Structure of testbench (cont.) Style 1 (cont.)



Another view of this: 3 chunks of Verilog, one for each of:




Module testAdd (testbench) generated inputs for module halfAdd (DUT) and display changes. Module tBench is top level

Structure of testbench (cont.)


Style 1 (cont.)

Structure of testbench (cont.) Style 2


Stimulus block instantiates Design block



Style 2 (cont.)


Style 2 (cont.)


// DUT



Style 2 (cont.)

Testbench techniques

$stop, $finish: stop and finish a simulation.

A stop simulation can be resumed, finish one can not.

30

Simulation control

UIT Circuit Design with HDL - Chapter 9

Testbench techniques Limiting data set

Instead of setting simulation time limit, a testbench can put a limit on the number of data put on inputs of a DUT


$random: generate random data


Applying synchronized data

Synchronize data with clock



Synchronized display of result


Testcases Test vector definition


Test vector definition State change


Test vector definition (cont.)




Question:

For the logic below, we got output average 3,

with the input a1=4, a2=2, a3=3, and a4=3.

The result is looks OK. However what kind of bugs may exist in

the logic?

Test vector definition (cont.) A sample answer


Test vector definition (cont.) Many kind of bugs escape through RTL simulation test. This means that

we can not be sage from bugs even if simulation test looks OK.

Therefore the following method is the most terrible way to fix bugs. Never do this way.


Example


Example 1


Example 1 (cont.)


Encoder 8-to-3

Example 2


module encoder8_3( output reg [2:0] encoder_out, input enable, input [7:0] encoder_in );

always @ (enable or encoder_in)

begin

if (enable)

case ( encoder_in )

8'b00000001 : encoder_out = 3'b000;

8'b00000010 : encoder_out = 3'b001;

8'b00000100 : encoder_out = 3'b010;

8'b00001000 : encoder_out = 3'b011;

8'b00010000 : encoder_out = 3'b100;

8'b00100000 : encoder_out = 3'b101;

8'b01000000 : encoder_out = 3'b110;

8'b10000000 : encoder_out = 3'b111;

default : $display("Check input bits.");

endcase

end

endmodule

Example 2 (cont.)


module stimulus; wire[2:0] encoder_out; reg enable; reg[7:0] encoder_in; reg [2:0] expected; encoder8_3 enc( encoder_out, enable, encoder_in ); initial begin enable = 1; encoder_in = 8'b00000010, expected = 3b001;

#1 $display("enable = %b, encoder_in = %b, encoder_out = %b, expected_out = %b", enable, encoder_in, encoder_out, expected);

#1 enable = 0; encoder_in = 8'b00000001; expected = 3b001; #1 $display("enable = %b, encoder_in = %b, encoder_out = %b, expected_out = %b

", enable, encoder_in, encoder_out, expected); #1 enable = 1; encoder_in = 8'b00000001; expected = 3b000; #1 $display("enable = %b, encoder_in = %b, encoder_out = %b, expected_out = %b

", enable, encoder_in, encoder_out, expected); #1 $finish; end endmodule

Example 2 (cont.)

Self-checking simulation


############################## Applying reset Came out of Reset Terminating simulation Simulation Result : PASSED ##############################

############################## Applying reset Came out of Reset Terminating simulation Simulation Result : FAILED ---- time=???, signal_value==???, expect_value=???-------- ##############################

Debuging


Debug by Synopsyss DVE tool

Source: http://www.synopsys.com/Tools/Verification/FunctionalVerification/Pages/VCS.aspx

Debuging (cont.)


Debug by Synopsyss DVE tool

Coverage report


Source: http://www.synopsys.com/Tools/Verification/FunctionalVerification/Pages/VCS.aspx

Coverage report (cont.)


Example of a code coverage report

Testbench State of the art


System Verilog has OPPs support to enhance the reusability,

special construct for randomization and coverage.

There are multiple such industry level standard verification

methodologies such as VMM, OVM and UVM.

These methodologies also provide set of base class libraries

and utilities that are very useful across the entire spectrum of

verification activities

More reference http://www.asic-world.com/verilog/art_testbench_writing.html

http://testbench.in/


Date post:	24-Sep-2015
Category:	Documents
Upload:	ki-ki
View:	10 times
Download:	0 times

Chapter 9_Testbench Verification

Documents