New Methods for Efficient Functional Testing of SoCs

New Methods for Efficient Functional Testing of SoCs

Matteo SONZA REORDA

www.cad.polito.it

Matteo SONZA REORDA – Politecnico di Torino 2

Summary

Introduction Processor testingPeripheral testingHW supportConclusions


Introduction

Typical SoCs includeOne or more processor coresSeveral memory modulesOther modules, including custom (digital

and analog) logic, and peripheral cores


SoC test

Possible solutions heavily depend on the origin of the cores the test solutions they support

They include scan test for logic and processor(s)BIST (especially for memories) functional test (for both single modules and

whole system)


Major issues: scan test

Scan test is a mature and well-known (and supported) approach, but may not be usable if

it is not supported by the core AND the netlist is not available

could give low defect coverage (it mainly targets stuck-at faults, only) if the SoC must work at high frequency, or with advanced technologies

if the number of cores is high, may require a significant amount of work to connect the scan chains to the outside


Major issues: BIST

Very popular for memories Increasingly popular for logic blocks Able to provide high defect coverage (normally

at-speed test) Normally requires an extensive modification of

the HW (typically performed by the module provider)

Requires understanding and adopting a given protocol for test activation and result extraction


Major issues: functional test

It aims at testing the functions rather than the faults; therefore, it may require limited structural information

It is based on exercising the system (or a given module) with suitable stimula, with minor (or without) test reconfiguration

This test can often be performed at-speed may be able to catch a good percentage of defects

but it requires suitable stimula ad hoc mechanisms for accessing each core during test


Test architecture

The complexity of SoCs raises issues in terms ofTest access mechanismsTest program generation Interfacing with the external ATETest length (duration and size)DiagnosisDebug…


Test access mechanisms

Popular solutions are based on IEEE 1149.1 for interfacing the device with

the outside IEEE 1500 for defining

the test interface of each core the test interconnection between the cores and

the TAP


SoC Architecture: normal mode

SoC

ProcessorCore

Memory Core1 Core2

Functional Bus

PeripheralCore1

PeripheralCore2


SoC Architecture: test mode

SoC

ProcessorCore

Memory Core1 Core2

PeripheralCore1

PeripheralCore2

TAP

ATEFunctional Bus

SI1-SO1

BIST

SI2-SO2

BIST


SoC Architecture: test mode 2

SoC1500 wrapper 1500 wrapper

1500 wrapper

ProcessorCore

Memory Core1

1500 wrapper

Core2

1500 wrapper 1500 wrapper

PeripheralCore1

PeripheralCore2

TAP

ATE


Trends

Standard interface for all coresEasier test program generationPossible test program generation automation

Signals between ATE and cores are commands instead of vectors

The frequency of test commands is independent on the test frequencyLow-cost ATE


Processor test

Most common approachesScan testBIST (for internal memories, and for large

internal logic blocks)Functional test


Functional test

Based on forcing the processor to execute a proper test program, and then checking the results

Requires proper mechanisms toUpload the test programChecking the results


SoC Test Architecture

SOC

ATE

ProcessorCore

RAM Core1 Core2

DMAController

Internal Bus


Test Protocol

Configure the SoC in Test ModeLoad the Test Program in the internal code

memory (e.g., through the DMA controller)Force the processor to execute the Test

ProgramCheck the results

This approach is often called Software-Based Self-Test (SBST)


Result check

The correctness of the results of the test program may be checked by forcing it to write to (and by observing) the memorysome proper (and easily observable) output

ports some externally accessible bus


Advantages

Low-cost ATEAt-speed testLimited hardware resources


Test stimula generation

May be based onStimula from the designer (e.g., intended for

design validation)Random stimulaAd hoc stimula, manually or automatically

generated

In any case, a test coverage metric should be available


Processor test generation

May be performed byThe processor core providerThe processor core user

Main problems:How to manage test program execution?How to observe its behavior?How to get a good test program?


Test generation for processors (I)

Test architecture: Papachristou et al. (DAC99)

Test program generation:Thatte and Abraham (TonC80)Batcher and Papachristou (VTS99) Chen and Dey (VTS2000)

Processor verification:Shen et al. (DAC99)Utamaphethai et al. (VLSI Design 99)


Test Program Generation

Manually, following guidelines and algorithms

Automatically


Manual Methods

Empirical methodsGlobal methodsUnit-oriented methods


Empirical methods

They are based on the knowledge of the Instruction Set Architecture (ISA), only

ExamplesAll instructionsAll instructions with all addressing modesAll code fragments to stimulate all units ...

No metrics are normally used


Global methods

Aim at testing the whole processor starting from the ISA, only

They are based on a systematic approach

They do not guarantee a given fault coverage, although significant values can normally be reached


Thatte, Abraham [TonC84]

Works on the RTL description of a simple processor, only, as it can be extracted from a user manual

Defines rules to build a graph describing the instruction behavior wrt registers

Defines a set of functional fault modelsDefines some procedures to generate

sequences of instructions addressing the above fault models


Processor graph

One vertex for every register (including special register, such, as PC)

Two special vertices (IN and OUT) for memory and I/O

One edge for every data transfer from one register (or memory, or I/O) and another; each edge is labeled with the identifier of the corresponding instruction


Functional fault models

For the register decoding function When a register is written

All the registers are written No register is written Another register is written

For the instruction decoding and control function

For the data storage function For the data transfer function For the data manipulation function


Procedures for test generation

They allow detecting all the previously listed faults (one at a time)

ExampleTo test the register decoding faults

Initialize all registers to a given value ZEROFor every register

Write a value ONE in the register Read the register Read the other registers


Unit-oriented methods

They provide a sequence of operations able to exhaustively cover a given unit (e.g., an arithmetic one)


Automatic methods

Macro-based methodsEvolutionary-based methods


Macro-based approach

A Macro is the basic block of the Test Program

Each macro:Focuses on a single target instruction in the

µP Instruction Set Includes the code for

Exciting the instruction functionalitiesMaking the results observable


Example #1

The macro for the ADD instruction is:

MOV AX, K1 ; load register AX with K1

MOV BX, K2 ; load register BX with K2

ADD AX, BX ; sum BX to AX

MOV RW, AX ; write AX to RW

MOV RW, PSW ; write status reg to RW

Observable register

EXCITATIONPHASE

OBSERVATIONPHASE

Macro parameters


Example #2

The macro for the JG instruction is:

MOV BX, 0 ; clear BX

MOV AX, K1

CMP AX, K2 ; compare AX with K2

JG Label ; jump if AX > K2

MOV BX, 1 ; move 1 to BX

Label: MOV RW, BX; write BX to RW


Macro Selection andParameter Optimization

do{ m = select_a_macro();

O = select_the_operands(m);F = compute_detected_faults(m, O);

if( F is not empty ) add m(O) to the test program;}while( stopping_condition() == FALSE );


Macro Selection

The final Test Program should have minimal length

An adaptive approach has been adopted: Macros are selected on a random basis A selection probability is associated to each macro At the beginning, all macros have the same

selection probability Each time a macro is selected, its selection

probability is increased if it detected at least one fault, decreased elsewhere


Operands

Each macro has some parameters: Immediate valuesMemory cell addresses…


Operand Selection

An Evolutionary approach has been adopted:Random values are initially chosenAn evaluation function is associated to each

set of valuesCurrent values are possibly improved using

a Genetic Algorithm


Evaluation Function

It is based on three terms:A first order term, corresponding to the

number of detected faultsA second order term, corresponding to the

number of excited faultsA third order term, corresponding to the

activity caused by the excited faults

The value of the evaluation function is computed by fault simulation


Experimental Results

The proposed method has been evaluated on:A prototype (named ATPGS) implementing

the proposed approachAn Intel 80C51 model


ATPGS architecture

ATPGKernel

GA FaultSimulator

µPnetlist

FaultList

MacroLibrary

TestProgram

Macro + Operands

Detected Faults

Macr

os


Case Study: i8051 µC

8-bit microprocessor developed by Intel in the 80sQuite old but still popular (USB)128 bytes directly-accessible data memory

+ 32 bytes bit-addressable data memory64KB external memory accessible using a

special instruction (MOVX)4KB internal + 64KB external program

memory


Case Study: i8051 µC (2)

RT-Level description7,500 VHDL lines4 KB program + 2 KB data memory

Gate-Level description12K gates28,792 stuck-at faults


Case Study: i8051 µC (3)

Instruction Set: 44 instructions from 0-operand ones (e.g., DIV AB) to 3-operand (e.g., CJNE Op1, Op2, R)

Non-orthogonalInstruction Library: 81 entries

prologue, epilogue66 sequential operations 13 conditional branches


Results

#Macros 213

Macro Generation 2 days of an experienced programmer

Parameter Optimization 24 h (CPU time)

Fault Coverage 92%

Test Program Length 624 instructions


Reference Results (stuck-at FC)

80%

92%94%

RandomTest Program

GenerationATPGS Full-scan

version


Result Analysis

Most of the undetected faults are in the Divider:

better results could be obtained by running a combinational ATPG for computing the optimum parameters and removing untestable faults

A nearly complete fault coverage has been obtained for the Control Unit


The µGP approach

Based on an evolutionary algorithm (named µGP)

Suitable internal representation, evaluation function and operators are defined

System architecture for automatic test program generation has been devised


Test Program Generator

Cultivates a population of µ individuals (DAG)

In each generation: λ new individuals are generated mutating

existing ones the best µ from (µ+λ) are selected for

surviving

Stop condition: steady stateSelection: tournament selection (τ)


Individual Representation

ADD ADDCAJMPANLCJNECLRCPLDADECDIVDJNZINCJBJBCJCJMPJNBJNCJNZJZLJMPMOVMOVCMOVXMULNOPORLPOPPUSHRLRLCRRRRCSETBSJMPSUBB…

Instruction library

A

B

C

D

E

F

H

Prologue

Epilogue

ADD ADDCAJMPANLCJNECLRCPLDADECDIVDJNZINCJBJBCJCJMPJNBJNCJNZJZLJMPMOVMOVCMOVXMULNOPORLPOPPUSHRLRLCRRRRCSETBSJMPSUBB…

Instruction library

A

B

C

D

E

F

H

Prologue

Epilogue

ORL A, reg

ORL C, /num

ORL C, !num

ORL A, #num

ORL num, reg

PARAMETERS

PreviousNode

NextNode

reg = R1

ORL A, R1

Instructionlibrary

ORL A, reg

ORL C, /num

ORL C, !num

ORL A, #num

ORL num, reg

PARAMETERS

PreviousNode

NextNode

reg = R1

ORL A, R1

Instructionlibrary


Evolutionary Operators

Add node (sequential or branch)Remove nodeModify the parameters of a nodeCrossover


Auto Adaptation

MicroGP internally tunesnumber of consecutive mutations activation probabilities of all operators

Significant performances improvement


System Architecture

generator

testprogram

instructionlibrary

netlist

faultsimulator

generator

testprogram

instructionlibrary

netlist

faultsimulator


System Architecture

generator

testprogram

instructionlibrary

netlist

faultsimulator

generator

testprogram

instructionlibrary

netlist

faultsimulator

simple description of µP assembly language syntax

test program evaluator

µGP evolutionary engine


MicroGP Test Program

Sun Enterprise 250 running at 400 MHz 2 Gbytes of RAMTest program generated in few days

Used for fault simulationsEvolutionary calculations required negligible

CPU time


Test Programs Comparison

General applicationsFibonacci, int2bin

Exhaustive test benchprovided by i8051 designer

ATPGSDATE01


Test Programs Comparison (2)

Random (comparable CPU)Same number of random test programsSame number random sequences of

macros (DATE01)


Experimental Results (%FC)

0

10

20

30

40

50

60

70

80

90

100

Fib

on

acci

int2

bin

TestA

ll

Ran

do

m

Ran

do

m

Macro

AT

PG

S

Mic

roG

P

FC%


HW support

Some HW can be added to the SoC (without modifying any core) to support the test


I-IP-based Approach

ATE

SoC

Processor Core

I-IP

Memory

An I-IP manages the execution of the

Software-based Self Test


I-IP tasks

Support the upload of the test-program into the code memory

Force the microprocessor to run the self-test procedure

Collect the resultsInteract with the ATE


Test Architecture

Data Memory

System Bus

CPU

Self-testdata

Interrupt port

Instruction Memory

Self-Testcode

TESTACTIVATION

UPLOADRESULT

1500 WRAPPER

Select

I-IPATE


Test program upload

The I-IP takes the control of the bus through a circuitry directly connected to the memory


Self-test activation

The self-test program corresponds to an Interrupt Service Routine

An interrupt request activates the test execution


Result monitoring

A test signature is generated by means of a MISR module

The MISR register is connected to a processor port

The test procedure writes results to the processor port


Communication with the ATE

A 1500-compliant wrapper is in charge of receiving commands from the ATE and sending data to it

High-level commands:Load the test programRun the testRead the test statusRead the results


Experimental analysis

2 case studies have been considered: Intel 8051SPARC Leon I

RT-Level behavioral VHDL descriptionCommercial synthesis toolAlready existing test programs (Corno et

al. [DATE03])


Area Overhead

Intel 8051Processor core: 25,292 gates I-IP: 490 gates1500 wrapper: 1,580 gatesArea overhead: 8.1%

SPARC Leon IProcessor core: 65,956 gates I-IP: 3,632 gates1500 wrapper: 2,263 gatesArea overhead: 8.9%


Test program details

Intel 8051Program size: 1,234 bytesProgram duration: 8,768 clock cyclesSA fault coverage: 95%

SPARC Leon IProgram size: 1,678 bytesProgram duration: 21,552 clock cyclesSA fault coverage: 94%


Debug

The I-IP can be usefully exploited also for debug (if the µP does not support other features)Can be programmed from the outside (e.g.,

to trigger an interrupt when a given address flows on the bus)

Can force the processor to execute a procedure that accesses to any register or memory word


On-line test

SBST can be used for on-line test, tooShort test procedures can be activated

periodically, or during idle timesThey must be written in such a way that

they don't interfere with the µP normal behavior


Delay faults

Rising performances and complexity of today’s microprocessors

Higher working frequenciesTraditional fault models no longer

sufficient

⇒ At-speed delay test is often required


Path-delay fault

The cumulative delay of a combinational path exceeds some specified duration

1

2


Path-delay fault testing [cont.]

1→0

2

- 0

Non-robust test

- 1

1

Tests consist of vector pairs (V1, V2)

Excitation and Propagation required.


Test application: scan-based

Shift out dataShift in dataScan

Enable

Clock

Launch clock Capture clock

Shift out dataShift in dataScan

Enable

Clock

Launch clock Capture clock

a) Launch-on-shift (LOS)

b) Launch-on-capture (LOC)


Test application: functional

clk

i – 1 i i + 1

V2 (i – 1)V1 (i )

V2 (i )V1 (i + 1)

Software-Based Self-TestThe test vectors reach the path inputs during

normal at-speed circuit operations Fault excitation and results observation

depend on data/instructions sequences


Path-Delay fault testability

Not all faults are testableStructurally sensitizable pathsFunctionally sensitizable paths

SBST techniques target functionally sensitizable faults, only

All faultsAll faults


Proposed approach

The flow is based on three steps:1. Fault list selection and classification

2. Fault excitation conditions learning

3. Fault excitation refinement and error propagation enhancement


1. Fault list selection/classification

Path-Delay fault list generationStatic Timing Analysis

Structurally untestable faults pruningStructurally coherent path-delay fault

classificationaimed at concentrate the test generation

efforts on specific processor areas



Concentrates on a structurally coherent fault set

Aim: generate a test program to excite at least one fault

This step is based onAn evolutionary algorithm to generate test

programsAn evaluation algorithm to assess a test

program’s ability to cover the addressed faults



Test programpopulation

Test program Evolutionary

algorithm

Structurally coherent

path-delay fault list

Evaluationalgorithm

Max FitnessValue

capture CK



Aims: Increase the number of excited pathsEnhance error propagation through addition

of I/O instructions

This step is based on:An evolutionary algorithm to optimize test

programsHardware-accelerated fault grading (FPGA)



learnedTest program

population

mutatedTest

programEvolutionary

algorithm

Structurally Coherent


Hardware-acceleratedevaluator

Excitation/Propagation

Fitnessvalues



learnedTest program

population

mutatedTest

programEvolutionary

algorithm

Structurally Coherent


Hardware-acceleratedevaluator

Excitation/Propagation

Fitnessvalues

Optimization of theOptimization of thetest program population:test program population:application of genetic mutations on Assembly test programs

MOV R1, 10MOV R2, 15ADD R1, R2

MOV R3, 10MOV R2, 18ADD R1, R2



FPGA

InstrumentedProcessor-based

system

Programmemory

Fault simulationcontroller

Test programupload

Results download

start/stop



1A

B

C

D

2FF

FF

EXC

enable

Activation condition logicFault injection logic


Case study

Intel 8051 microcontrollerConnected to external

program memory coreParallel output ports

connected to MISRfor results observation

8051µprocessor

Programmemory

System bus

MIS

R


Case study [cont.]

1. Fault list selection/classification 1,403 worst paths extracted with

Synopsys Tetramax 234 of them are structurally

sensitizable “true” paths Automatically classified into 18

coherent fault sets (each including 30 paths max)


Case study [cont.]

2. Fault excitation conditions learning Evolutionary tool: µGP Ad-hoc evaluation tool

Targets non-robust coverage 1,000 lines of C code Interacts with Mentor Graphics Modelsim


Case study [cont.]


Evolutionary tool: µGP Sabotaged circuit mapped on FPGA

Fault grading @ 15 MHz


Case study [cont.]

1,827 K1.3 K8689mutated set

611 K0.5 K2746learned set

lenght[cc]

size[bytes]

Propagated[#]

Excited[#]

91.0 hourson a SUN Ultra 250

workstation @ 400 MHz

8.8 hours

136 M4.5 K1223stuck-at set


Peripheral testing

Peripheral cores can also be tested viaScan testFunctional test

In the latter case, the test requiresA suitable test program

To program the peripheralTo exercize the peripheral

Some external data (either in input or output)


Functional test for peripherals

Testing peripherals using functional test may follow two strategiesTesting the peripheral working in the

configuration that is used by a given application, only

Testing the peripheral working in all possible configurations


Peripheral testing

It requiresConfiguring the peripheral (configuration

code fragment)Exercising the peripheral (functional

fragment, including code and data)


Test architecture

SoC

Microprocessor

core

Memory

core

Input/Output

peripheral core

Output

periperhal core

Input

peripheral core

BU

S

ATE

Logic core


Test stimula generation

It can be done in different ways:Manually or automaticallyStarting from a data-sheet, an RT-level

description, a gate-level description

Suitable metrics are required to guide generation (and to stop it)


RT-level coverage metrics

The most popular ones are Statement coverage Branch coverage Condition coverage Expression coverage

It is common practice to maximize all of them Crucial issues

Which is the most suitable order for the metrics to be considered?

Which is the maximum value for each metric?



The most popular ones are Statement coverage Branch coverage Condition coverage Expression coverage.

It is common practice to maximize all of them. Crucial issues



It depends on the description style



The most popular ones are Statement coverage Branch coverage Condition coverage Expression coverage.

It is common practice to maximize all of them. Crucial issues



100% is not always achievable (e.g., due to

unreachable statements)


High-level metrics representativeness

Can we forecast gate-level stuck-at fault coverage by only looking at RT-level metrics?


Case of study

UART

Motorola 6809 Microprocessor

RAM Memory

Transmitter Module

Receiver Module

Configuration Logic Module

PIA

SoC

BUS

8

1

1

Configuration and functionality module


Details

Description PIA UART

RT-level

# statements 149 383

# branches 134 182

# conditions 75 73

# expressions

N/A 54

Gate-level# gates 1,016 2,247

# faults 1,938 4,054


PIA results

PIA Test SetsCode Coverage

[%]

Test TimeTest Blocks

Fault coverage

[# clock cycle]

[#] [%]

Final test Set

Statement 99.7

625 9 96.2Branch 98.5

Condition 98.9

Expression -


UART results

UART Test SetsCode Coverage

[%]Test Time

Test Blocks

Fault Coverage

[# clock cycle]

[#] [%]

Step 1

Statement 97,2

2,050 8 86.1Branch 98,9

Condition 98,1

Expression 72.9

Step 2

Statement 99.2

4,300 14 94.3Branch 99.5

Condition 99.7

Expression 99.6


UART results

UART Test Sets Code Coverage [%] Test Time

Test Blocks

Fault Coverage

[# clock cycle]

[#] [%]

Step 1

Statement 97,2

2,050 8 86.1Branch 98,9

Condition 98,1

Expression 72.9

Step 2

Statement 99.2

4,300 14 94.3Branch 99.5

Condition 99.7

Expression 99.6

Maximizing one metric, only, is not enough


UART results

UART Test Sets Code Coverage [%] Test Time

Test Blocks

Fault Coverage

[# clock cycle]

[#] [%]

Step 1

Statement 97,2

2,050 8 86.1Branch 98,9

Condition 98,1

Expression 72.9

Step 2

Statement 99.2

4,300 14 94.3Branch 99.5

Condition 99.7

Expression 99.6

Test time is much longer than for PIA, due to

different conditions to test (parity, overrun, etc.)


UART results

UART Test SetsCode Coverage

[%]Test Time

Test Blocks

Fault Coverage

[# clock cycle]

[#] [%]

Step 1

Statement 97,2

2,050 8 86.1Branch 98,9

Condition 98,1

Expression 72.9

Step 2

Statement 99.2

4,300 14 94.3Branch 99.5

Condition 99.7

Expression 99.6

Maximizing RT-level metrics can guarantee good gate-level fault

coverage


Conclusions

Functional test for SoCs is increasingly popular in industry is a hot research topic

Hybrid solution combining it with DfT may be effective

Effective test generation is still an open problem

Documents

New Methods for Efficient Functional Testing of SoCs