New Methods for Efficient Functional Testing of SoCs

1
New Methods for Efficient Functional Testing of
SoCs

• Matteo SONZA REORDA

www.cad.polito.it
2
Summary

• Introduction
• Processor testing
• Peripheral testing
• HW support
• Conclusions

3
Introduction

• Typical SoCs include
• One or more processor cores
• Several memory modules
• Other modules, including custom (digital and
  analog) logic, and peripheral cores

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

5
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

6
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

7
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

8
Test architecture

• The complexity of SoCs raises issues in terms of
• Test access mechanisms
• Test program generation
• Interfacing with the external ATE
• Test length (duration and size)
• Diagnosis
• Debug

9
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

10
SoC Architecture normal mode
SoC
Memory
Core1
Core2
Functional Bus
PeripheralCore1
PeripheralCore2
Processor Core
11
SoC Architecture test mode
SoC
SI1-SO1
Memory
Core1
Core2
BIST
BIST
ATE
Functional Bus
TAP
PeripheralCore1
PeripheralCore2
Processor Core
SI2-SO2
12
SoC Architecture test mode 2
SoC
1500 wrapper
1500 wrapper
1500 wrapper
Memory
Core1
Core2
ATE
TAP
1500 wrapper
1500 wrapper
1500 wrapper
PeripheralCore1
PeripheralCore2
Processor Core
13
Trends

• Standard interface for all cores
• Easier test program generation
• Possible test program generation automation
• Signals between ATE and cores are commands
  instead of vectors
• The frequency of test commands is independent on
  the test frequency
• Low-cost ATE

14
Processor test

• Most common approaches
• Scan test
• BIST (for internal memories, and for large
  internal logic blocks)
• Functional test

15
Functional test

• Based on forcing the processor to execute a
  proper test program, and then checking the
  results
• Requires proper mechanisms to
• Upload the test program
• Checking the results

16
SoC Test Architecture
SOC
RAM
Core1
Core2
Internal Bus
Processor Core
DMAController
ATE
17
Test Protocol

• Configure the SoC in Test Mode
• Load the Test Program in the internal code memory
  (e.g., through the DMA controller)
• Force the processor to execute the Test Program
• Check the results
• This approach is often called Software-Based
  Self-Test (SBST)

18
Result check

• The correctness of the results of the test
  program may be checked by forcing it to write to
  (and by observing)
• the memory
• some proper (and easily observable) output ports
• some externally accessible bus

19
Advantages

• Low-cost ATE
• At-speed test
• Limited hardware resources

20
Test stimula generation

• May be based on
• Stimula from the designer (e.g., intended for
  design validation)
• Random stimula
• Ad hoc stimula, manually or automatically
  generated
• In any case, a test coverage metric should be
  available

21
Processor test generation

• May be performed by
• The processor core provider
• The processor core user
• Main problems
• How to manage test program execution?
• How to observe its behavior?
• How to get a good test program?

22
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)

23
Test Program Generation

• Manually, following guidelines and algorithms
• Automatically

24
Manual Methods

• Empirical methods
• Global methods
• Unit-oriented methods

25
Empirical methods

• They are based on the knowledge of the
  Instruction Set Architecture (ISA), only
• Examples
• All instructions
• All instructions with all addressing modes
• All code fragments to stimulate all units
• ...
• No metrics are normally used

26
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

27
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 models
• Defines some procedures to generate sequences of
  instructions addressing the above fault models

28
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

29
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

30
Procedures for test generation

• They allow detecting all the previously listed
  faults (one at a time)
• Example
• To test the register decoding faults
• Initialize all registers to a given value ZERO
• For every register
• Write a value ONE in the register
• Read the register
• Read the other registers

31
Unit-oriented methods

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

32
Automatic methods

• Macro-based methods
• Evolutionary-based methods

33
Macro-based approach

• A Macro is the basic block of the Test Program
• Each macro
• Focuses on a single target instruction in the mP
  Instruction Set
• Includes the code for
• Exciting the instruction functionalities
• Making the results observable

34
Example 1
Macro parameters

• 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

EXCITATIONPHASE
OBSERVATIONPHASE
35
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 gt K2
• MOV BX, 1 move 1 to BX
• Label MOV RW, BX write BX to RW

36
Macro Selection andParameter Optimization

• do m select_a_macro() O
  select_the_operands(m) F compute_detected_faul
  ts(m, O) if( F is not empty ) add m(O) to
  the test programwhile( stopping_condition()
  FALSE )

37
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

38
Operands

• Each macro has some parameters
• Immediate values
• Memory cell addresses

39
Operand Selection

• An Evolutionary approach has been adopted
• Random values are initially chosen
• An evaluation function is associated to each set
  of values
• Current values are possibly improved using a
  Genetic Algorithm

40
Evaluation Function

• It is based on three terms
• A first order term, corresponding to the number
  of detected faults
• A second order term, corresponding to the number
  of excited faults
• A third order term, corresponding to the activity
  caused by the excited faults
• The value of the evaluation function is computed
  by fault simulation

41
Experimental Results

• The proposed method has been evaluated on
• A prototype (named ATPGS) implementing the
  proposed approach
• An Intel 80C51 model

42
ATPGS architecture
ATPGKernel
MacroLibrary
TestProgram
Macros
Macro Operands
GA
FaultSimulator
Detected Faults
mPnetlist
FaultList
43
Case Study i8051 mC

• 8-bit microprocessor developed by Intel in the
  80s
• Quite old but still popular (USB)
• 128 bytes directly-accessible data memory 32
  bytes bit-addressable data memory
• 64KB external memory accessible using a special
  instruction (MOVX)
• 4KB internal 64KB external program memory

44
Case Study i8051 mC (2)

• RT-Level description
• 7,500 VHDL lines
• 4 KB program 2 KB data memory
• Gate-Level description
• 12K gates
• 28,792 stuck-at faults

45
Case Study i8051 mC (3)

• Instruction Set 44 instructions
• from 0-operand ones (e.g., DIV AB)
• to 3-operand (e.g., CJNE Op1, Op2, R)
• Non-orthogonal
• Instruction Library 81 entries
• prologue, epilogue
• 66 sequential operations
• 13 conditional branches

46
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

47
Reference Results (stuck-at FC)
94
92
80
RandomTest ProgramGeneration
Full-scanversion
ATPGS
48
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

49
The mGP approach

• Based on an evolutionary algorithm (named mGP)
• Suitable internal representation, evaluation
  function and operators are defined
• System architecture for automatic test program
  generation has been devised

50
Test Program Generator

• Cultivates a population of m individuals (DAG)
• In each generation
• l new individuals are generated mutating
  existing ones
• the best m from (ml) are selected for surviving
• Stop condition steady state
• Selection tournament selection (t)

51
Individual Representation
52
Evolutionary Operators

• Add node (sequential or branch)
• Remove node
• Modify the parameters of a node
• Crossover

53
Auto Adaptation

• MicroGP internally tunes
• number of consecutive mutations
• activation probabilities of all operators
• Significant performances improvement

54
System Architecture
55
System Architecture
test program evaluator
simple description of mP assembly language syntax
mGP evolutionary engine
56
MicroGP Test Program

• Sun Enterprise 250 running at 400 MHz
• 2 Gbytes of RAM
• Test program generated in few days
• Used for fault simulations
• Evolutionary calculations required negligible CPU
  time

57
Test Programs Comparison

• General applications
• Fibonacci, int2bin
• Exhaustive test bench
• provided by i8051 designer
• ATPGS
• DATE01

58
Test Programs Comparison (2)

• Random (comparable CPU)
• Same number of random test programs
• Same number random sequences of macros (DATE01)

59
Experimental Results (FC)
60
HW support

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

61
I-IP-based Approach
SoC
Processor Core
Memory
I-IP
An I-IP manages the execution of the
Software-based Self Test
ATE
62
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 results
• Interact with the ATE

63
Test Architecture
Instruction Memory
Data Memory
Self-test
Interrupt port
data
Self-Test
CPU
code
System Bus
Select
TEST
UPLOAD
RESULT
ACTIVATION
I-IP
ATE
1500 WRAPPER
64
Test program upload

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

65
Self-test activation

• The self-test program corresponds to an Interrupt
  Service Routine
• An interrupt request activates the test execution

66
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

67
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 program
• Run the test
• Read the test status
• Read the results

68
Experimental analysis

• 2 case studies have been considered
• Intel 8051
• SPARC Leon I
• RT-Level behavioral VHDL description
• Commercial synthesis tool
• Already existing test programs (Corno et al.
  DATE03)

69
Area Overhead

• Intel 8051
• Processor core 25,292 gates
• I-IP 490 gates
• 1500 wrapper 1,580 gates
• Area overhead 8.1
• SPARC Leon I
• Processor core 65,956 gates
• I-IP 3,632 gates
• 1500 wrapper 2,263 gates
• Area overhead 8.9

70
Test program details

• Intel 8051
• Program size 1,234 bytes
• Program duration 8,768 clock cycles
• SA fault coverage 95
• SPARC Leon I
• Program size 1,678 bytes
• Program duration 21,552 clock cycles
• SA fault coverage 94

71
Debug

• The I-IP can be usefully exploited also for debug
  (if the mP 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

72
On-line test

• SBST can be used for on-line test, too
• Short test procedures can be activated
  periodically, or during idle times
• They must be written in such a way that they
  don't interfere with the mP normal behavior

73
Delay faults

• Rising performances and complexity of todays
  microprocessors
• Higher working frequencies
• Traditional fault models no longer sufficient
• ? At-speed delay test is often required

74
Path-delay fault

• The cumulative delay of a combinational path
  exceeds some specified duration

2
1
75
Path-delay fault testing cont.

• Tests consist of vector pairs (V1, V2)
• Excitation and Propagation required.

- 1
2
- 0
1
1?0
Non-robust test
76
Test application scan-based
Shift out data
Shift in data
ScanEnable
Clock
Launch clock
Capture clock
a) Launch-on-shift (LOS)
Shift out data
Shift in data
ScanEnable
Clock
Launch clock
Capture clock
b) Launch-on-capture (LOC)
77
Test application functional

• Software-Based Self-Test
• The test vectors reach the path inputs during
  normal at-speed circuit operations
• Fault excitation and results observation depend
  on data/instructions sequences

i 1
i
i 1
clk
V2 (i 1) V1 (i )
V2 (i ) V1 (i 1)
78
Path-Delay fault testability
All faults

• Not all faults are testable
• Structurally sensitizable paths
• Functionally sensitizable paths
• SBST techniques target functionally sensitizable
  faults, only

79
Proposed approach

• The flow is based on three steps
• Fault list selection and classification
• Fault excitation conditions learning
• Fault excitation refinement and error propagation
  enhancement

80
1. Fault list selection/classification

• Path-Delay fault list generation
• Static Timing Analysis
• Structurally untestable faults pruning
• Structurally coherent path-delay fault
  classification
• aimed at concentrate the test generation efforts
  on specific processor areas

81
2. Fault excitation conditions learning

• Concentrates on a structurally coherent fault set
• Aim generate a test program to excite at least
  one fault
• This step is based on
• An evolutionary algorithm to generate test
  programs
• An evaluation algorithm to assess a test
  programs ability to cover the addressed faults

82
2. Fault excitation conditions learning
Test program population
Structurally coherent path-delay fault list
Evolutionary algorithm
Evaluation algorithm
Test program
Max Fitness Value capture CK
83
3. Fault excitation refinement and error
propagation enhancement

• Aims
• Increase the number of excited paths
• Enhance error propagation through addition of I/O
  instructions
• This step is based on
• An evolutionary algorithm to optimize test
  programs
• Hardware-accelerated fault grading (FPGA)

84
3. Fault excitation refinement and error
propagation enhancement
learned Test program population
Structurally Coherent path-delay fault list
Evolutionary algorithm
Hardware- accelerated evaluator
mutatedTest program
Excitation/ Propagation Fitness values
85
3. Fault excitation refinement and error
propagation enhancement
learned Test program population
Structurally Coherent path-delay fault list
Optimization of thetest program
population application of genetic mutations on
Assembly test programs
Evolutionary algorithm
Hardware- accelerated evaluator
mutatedTest program
MOV R1, 10 MOV R2, 15 ADD R1, R2
MOV R3, 10 MOV R2, 18 ADD R1, R2
Excitation/ Propagation Fitness values
86
3. Fault excitation refinement and error
propagation enhancement
FPGA
Instrumented Processor-based system
Program memory
Test program upload
Fault simulation controller
start/stop
Results download
87
3. Fault excitation refinement and error
propagation enhancement
D
C
2
FF
B
1
A
88
Case study

• Intel 8051 microcontroller
• Connected to externalprogram memory core
• Parallel output portsconnected to MISRfor
  results observation

8051 ?processor
Program memory
MISR
System bus
89
Case study cont.

• 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)

90
Case study cont.

• Fault excitation conditions learning
• Evolutionary tool mGP
• Ad-hoc evaluation tool
• Targets non-robust coverage
• 1,000 lines of C code
• Interacts with Mentor Graphics Modelsim

91
Case study cont.

• Fault excitation refinement and error propagation
  enhancement
• Evolutionary tool mGP
• Sabotaged circuit mapped on FPGA
• Fault grading _at_ 15 MHz

92
Case study cont.
91.0 hourson a SUN Ultra 250 workstation _at_ 400
MHz
lenght cc
size bytes
Propagated
Excited
611 K
0.5 K
27
46
learned set
1,827 K
1.3 K
86
89
mutated set
8.8 hours
93
Peripheral testing

• Peripheral cores can also be tested via
• Scan test
• Functional test
• In the latter case, the test requires
• A suitable test program
• To program the peripheral
• To exercize the peripheral
• Some external data (either in input or output)

94
Functional test for peripherals

• Testing peripherals using functional test may
  follow two strategies
• Testing the peripheral working in the
  configuration that is used by a given
  application, only
• Testing the peripheral working in all possible
  configurations

95
Peripheral testing

• It requires
• Configuring the peripheral (configuration code
  fragment)
• Exercising the peripheral (functional fragment,
  including code and data)

96
Test architecture
97
Test stimula generation

• It can be done in different ways
• Manually or automatically
• Starting from a data-sheet, an RT-level
  description, a gate-level description
• Suitable metrics are required to guide generation
  (and to stop it)

98
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?

99
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?

It depends on the description style
100
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?

100 is not always achievable (e.g., due to
unreachable statements)
101
High-level metrics representativeness

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

102
Case of study
103
Details
104
PIA results
105
UART results
106
UART results
Maximizing one metric, only, is not enough
107
UART results
Test time is much longer than for PIA, due to
different conditions to test (parity, overrun,
etc.)
108
UART results
Maximizing RT-level metrics can guarantee good
gate-level fault coverage
109
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