Transcript Chapter 4

Chapter 4
System/Network-on-Chip
Test Architectures
EE141
System-on-Chip
Test Architectures
1
Ch. 4 – SOC and NOC Testing - P. 1
What is this chapter about?
 Introduce
basic and advanced
architectures for:
 System-on-Chip (SOC) Testing
 Network-on-Chip (NOC) Testing
 Further
focus on:
 Testing on On-Chip Networks
 Design and Test Practices in Industry
EE141
System-on-Chip
Test Architectures
2
Ch. 4 – SOC and NOC Testing - P. 2
Introduction to SoC Testing





SoC testing is a composite test comprised of individual
tests for each core, user-defined logic (UDL) tests, and
interconnect tests.
To avoid cumbersome format translation for IP cores,
SoC and core development working groups such as
virtual socket interface alliance (VSIA) have been formed
to propose standards.
IEEE 1500 standard has been announced to facilitate
SoC testing.
IEEE 1500 specifies interface standard which allows
cores to fit quickly into virtual sockets on SoC.
Core vendors produce cores with an uniform set of
interface features. SoC integration is simplified by
plugging cores into standardized sockets.
EE141
System-on-Chip
Test Architectures
3
Ch. 4 – SOC and NOC Testing - P. 3
Challenges of SoC Testing




Generally, core users cannot access core net-lists and
insert design-for-testability circuits. Core users rely on
test patterns supplied by core vendors.
Care must be taken to make sure that undesirable test
patterns and clock skews are not introduced into test
streams.
Cores are often embedded in several layers of userdefined or other core-based logic, and are not always
directly accessible from Chip I/Os.
Test data at I/Os of an embedded core might need to be
translated into a format for application to the core.
EE141
System-on-Chip
Test Architectures
4
Ch. 4 – SOC and NOC Testing - P. 4
Conceptual Architecture of Embedded CoreBased SoC Testing

Mainly, three structural elements are required. They are
test pattern source and sink, test access mechanism
(TAM), and core test wrapper.
EE141
System-on-Chip
Test Architectures
5
Ch. 4 – SOC and NOC Testing - P. 5
More Test Challenges



Once test data transport mechanism (TAM) and test
translation mechanism (test wrapper) are determined,
major challenge for system integrator is test scheduling.
Test scheduling must consider several conflicting factors:
(a) SoC test time minimization, (b) resource conflicts due
to sharing of TAMs and on-chip BIST engines, (c)
precedence constraints among tests, and (d) power
constraints.
Finally, analog and mixed-signal core testing must be
dealt with. Testing analog and mixed-signal cores is
challenging because their failure mechanisms and test
requirements are less known than digital cores.
EE141
System-on-Chip
Test Architectures
6
Ch. 4 – SOC and NOC Testing - P. 6
Talk Outline for SoC Testing

Introduction to testing
 Motivation for modular testing of SOCs

Wrapper design
 IEEE 1500 standard, optimization



Test access mechanism design and optimization
Test scheduling
Exploiting port scalability to test embedded cores at
multiple data rates
 Virtual TAMs
 Matching ATE data rates to scan frequencies of embedded cores

Conclusions
EE141
System-on-Chip
Test Architectures
7
Ch. 4 – SOC and NOC Testing - P. 7
System Chips
~50 million transistors
1 cm
1 cm
Viruses: Size 300 nm
Intel Itanium (2006): 1.7 billion transistors
EE Times:
Intel crafts transistor with 20-nm gate length
David Lammers, David Lammers
(06/11/2001)
EE141
System-on-Chip
Test Architectures
8
Ch. 4 – SOC and NOC Testing - P. 8
Motivation for Testing: XBox 360
Technical Problems



The "Red Ring of Death": Three red lights on the Xbox
360 indicator, representing "general hardware failure”
(http://en.wikipedia.org/wiki/3_Red_Lights_of_Death)
The Xbox 360 can be subject to a number of possible
technical problems. Since the Xbox 360 console was
released in 2005 the console gained reputation in the
press in articles portraying poor reliability and
relatively high failure rates.
On 5 July 2007, Peter Moore published an open letter
recognizing the problem and announcing 3 years
warranty expansion for every Xbox 360 console that
experiences the general hardware failure indicated by
the three flashing red lights on the console.
EE141
System-on-Chip
Test Architectures
9
Ch. 4 – SOC and NOC Testing - P. 9
XBox 360 Technical Problems (Cont’d)
July 5, 2007, Xbox issues to cost
Microsoft $1 billion-plus. Unacceptable
number of repairs leads to company
extending warranties.
 Matt Rosoff, an analyst at the
independent research group Directions
on Microsoft, estimates that Microsoft’s
entertainment and devices division has
lost more than $6 billion since 2002.

EE141
System-on-Chip
Test Architectures
10
Ch. 4 – SOC and NOC Testing - P. 10
Testing Principles (2-minute primer)
• Screen defective chips
(wafer, package)
• Stress test (burn-in)
• Diagnosis: Locate defects,
yield learning
EE141
System-on-Chip
Test Architectures
• Speed binning
• Design-for-testability (DFT)
typically used
• Test generation, scan design
11
Ch. 4 – SOC and NOC Testing - P. 11
Motivation for Core-Based SOC Testing

System-on-chip (SOC) integrated circuits based on embedded
intellectual property (IP) cores are now commonplace
 SOCs include processors, memories, peripheral devices, IP
cores, analog cores
 Low cost, fast time-to-market, high performance, low power
 Manufacturing test needed to detect manufacturing defects
Manufacturing
cost
Test cost
ITRS’03
EE141
System-on-Chip
Test Architectures
12
Ch. 4 – SOC and NOC Testing - P. 12
System-on-Chip (SOC)
• Test access is limited
• Test sets must be
transported to
embedded logic
• High test data volume & test time
I/O pads
Self-test
control
Legacy
core
IP hard
core
User-defined logic
Memory
array
DSP
core
Interface
control
I/O pads
I/O pads
CPU
core
Embedded
DRAM
1149.1 TAP controller
NXP NexperiaTM PNX8550 SOC: 338,839
flip-flops, 274 embedded cores, 10M logic gates, 40M logic transistors!
EE141
System-on-Chip
Test Architectures
13
Ch. 4 – SOC and NOC Testing - P. 13
Cost of Test
“The emergence of more advanced ICs and
SOC semiconductor devices is causing test costs
to escalate to as much as 50 percent of the total
manufacturing cost.” [Kondrat 2002]
 “As a result, semiconductor test cost continues to
increase in spite of the introduction of DFT, and
can account for up to 25-50% of total
manufacturing cost”. [Cooper 2001]
 “Test may account for more than 70% of the total
manufacturing cost - test cost does not directly
scale with transistor count, dies size, device pin
count, or process technology.” [ITRS’03]

EE141
System-on-Chip
Test Architectures
14
Ch. 4 – SOC and NOC Testing - P. 14
Modular Testing
• Test embedded cores using patterns provided by core vendor (test reuse)
• Test access mechanisms (TAMs) needed for test data transport: TAMs impact
test time and test cost
• Test wrappers translate test data supplied by TAMs
• TAM optimization, test scheduling, and test compression are critical
 Test data volume and testing time in 2010 will 30X that for today’s chips
[ITRS’05]
Automatic Test
Equipment (ATE)
Embedded
core
Embedded
core
SOC
TAM
Embedded
core
TAM
Wrapper
EE141
System-on-Chip
Test Architectures
15
Ch. 4 – SOC and NOC Testing - P. 15
Test Planning
Optimizing Test Access to Cores and Scheduling
Test Hardware
Test hardware planning
Core import
Core integration
Test wrapper
& TAM design
Top-level DFT
•Test control blocks
•IEEE 1149.1
EE141
System-on-Chip
Test Architectures
Test software planning
Core test import
Top-level ATPG
•Glue logic, soft cores
•Test wrappers
Test scheduling
Test assembly
16
Ch. 4 – SOC and NOC Testing - P. 16
IEEE 1500 Core Test Standard
Goals
 Define test interface between core and
SOC
 Core isolation
 Plug-and-play protocols
 Scope
 Standardize core isolation protocols and
test modes
 TAM design
 Type of test to be applied
 Test scheduling

EE141
System-on-Chip
Test Architectures
17
Ch. 4 – SOC and NOC Testing - P. 17
IEEE 1500 Wrapper
Wrapper Modes: (1) Normal; (2) Serial Test; (3) 1-N Test; (4) Bypass; (5)
Isolation; (6) Extest [Marinissen 2002]
EE141
System-on-Chip
Test Architectures
18
Ch. 4 – SOC and NOC Testing - P. 18
Wrapper Boundary Cells
EE141
System-on-Chip
Test Architectures
19
Ch. 4 – SOC and NOC Testing - P. 19
Wrapper Usage
EE141
System-on-Chip
Test Architectures
20
Ch. 4 – SOC and NOC Testing - P. 20
Wrapped Embedded Cores
EE141
System-on-Chip
Test Architectures
21
Ch. 4 – SOC and NOC Testing - P. 21
Wrapper Operation Modes (I)
Normal Mode
EE141
System-on-Chip
Test Architectures
Serial Bypass Mode
22
Ch. 4 – SOC and NOC Testing - P. 22
Wrapper Operation Modes (II)
Serial Internal Test Mode
EE141
System-on-Chip
Test Architectures
Serial External Test Mode
23
Ch. 4 – SOC and NOC Testing - P. 23
Wrapper Operation Modes (III)
Parallel Internal Test Mode
EE141
System-on-Chip
Test Architectures
Parallel External
24
Ch. 4 – SOC and NOC Testing - P. 24
Test Wrapper Optimization
Priority 1: Balanced Wrapper Scan Chains
Core
4 FF
Core
4 FF
8 FF
8 FF
Wrapper
Wrapper
Unbalanced
Balanced
Minimize length of longest wrapper scan in/out chain
EE141
System-on-Chip
Test Architectures
25
Ch. 4 – SOC and NOC Testing - P. 25
Reducing TAM Width
Priority 2: Minimize wrapper scan chains created
Scan chain – 32 FF
I
I
8 FF
I
8 FF
I
8 FF
O
4 Wrapper scan chains
O
2 Wrapper scan chains
Scan chain – 32 FF
I
I
I
I
8 FF
EE141
System-on-Chip
Test Architectures
8 FF
8 FF
O O
26
Ch. 4 – SOC and NOC Testing - P. 26
Two-Priority Wrapper Design Algorithm
Longest wrapper scan chain
1.
2.
Minimize length of
longest wrapper scan
in/out chain
Minimize number of
wrapper scan chains
Design_wrapper algorithm uses
the BFD heuristic for Bin Design
TAM width
EE141
System-on-Chip
Test Architectures
27
Ch. 4 – SOC and NOC Testing - P. 27
Test Access Mechanisms
Types of TAMs






Multiplexed access
[Immaneni, ITC’90]
Reuse system bus
[Harrod, ITC’99]
Transparent paths
[Ghosh, DAC’98]
Isolation rings
[Whetsel, ITC’97]
Test Bus [Varma,
ITC’98]
Test Rail
[Marinissen, ITC’98]
EE141
System-on-Chip
Test Architectures
C1
C2
C3
Multiplexed
C1
C2
C3
Daisychain
C1
C2
C3
Distribution
28
Ch. 4 – SOC and NOC Testing - P. 28
Test Bus Architecture
A
C
Schedule: Serial
B
D
E
F
SOC



 TAM width
Architecture
A
B
C
D
E
F
 test time
Combination of multiplexing and distribution
Supports only serial schedule
Core-external testing is cumbersome or impossible
EE141
System-on-Chip
Test Architectures
29
Ch. 4 – SOC and NOC Testing - P. 29
TestRail Architecture [Goel ITC’02]




Combination of Daisy chain and Distribution architectures
Cores connected to a TestRail can be tested simultaneously as well
as sequentially
Multiple wrappers can be activated simultaneously for Extest
TestRails can be either fixed-width or flexible-width
Flexible-width TestRails
Fixed-width TestRails
C1
C2
w1
C3
C1
C2
C3
W
C1
C2
w2
EE141
System-on-Chip
Test Architectures
C1
C2
30
Ch. 4 – SOC and NOC Testing - P. 30
Step-by-Step Approach to Wrapper/TAM
Co-optimization
1. PW: Wrapper design
2. PAW: Core assignment + PW
3. PPAW: TAM width partitioning + PAW
4. PNPAW: Number of TAMs + PPAW
W3
W2
W1
TAMs
IP
IP
Wrapper
Wrapper
EE141
System-on-Chip
Test Architectures
IP
Wrapper
31
Ch. 4 – SOC and NOC Testing - P. 31
Mathematical Programming Model for
TAM Partitioning





Variable xij = 1, if core i assigned to TAM j
Testing time of core i on TAM width wj = Ti(wj)
Testing time on TAM j = i Ti(wj) xij
Objective: Minimize T = maxj i Ti(wj) xij
Constraints
1. i xij = 1, every core connected to exactly one
TAM
2. i wj = W, total TAM width is W
3. wj  wmax, maximum width of any TAM is
wmax
EE141
System-on-Chip
Test Architectures
32
Ch. 4 – SOC and NOC Testing - P. 32
TAM Design and Test Scheduling



Given the test set parameters for the
cores and the total TAM width W
Assign a part of W to each core, design
a wrapper for each core, and determine
the test schedule,
Such that
 W is not exceeded at any time and

Testing time is minimized
EE141
System-on-Chip
Test Architectures
33
Ch. 4 – SOC and NOC Testing - P. 33
Architectures Determine Schedules
[Goel ’03]
Slide provided by Erik Jan Marinissen, NXP Research Labs
EE141
System-on-Chip
Test Architectures
34
Ch. 4 – SOC and NOC Testing - P. 34
Test Scheduling



Schedule

Test scheduling determines sequence of core tests on
the TAMs
Avoid test resource conflicts
Minimize testing time
Ineffective scheduling can increase tester data volume:
Idle bits
Idle bits
Core 1
Core 2
Core 5
Core 4
Time
EE141
System-on-Chip
Test Architectures
36
Ch. 4 – SOC and NOC Testing - P. 36
Rectangle Representation




Testing time Ti(wj) for
Core i and TAM
width j
Rectangle Rij
Set of rectangles Ri
for each core
Collection of
rectangles R for SOC
EE141
System-on-Chip
Test Architectures
Set Ri of rectangles
for Core i
Ti(wj)
wj
Collection R
37
Ch. 4 – SOC and NOC Testing - P. 37
Rectangle Packing Problem




Given collection R of rectangle sets for the SOC cores,
Select one rectangle Rij for each Core i
Pack the selected rectangles into a bin of fixed height,
Such that bin width is minimized
Width
Collection R
Core 1
Core 3
Core 2
EE141
System-on-Chip
Test Architectures
38
Ch. 4 – SOC and NOC Testing - P. 38
Packed Bin = TAM Design + Test Schedule
Rectangle area = tester
memory for core test
Empty space = wasted
tester memory
Core 8
Core 5
Core 2
Core 4
Core 7
Core 1
Core 3
Core 6
Bin width = SOC testing time
EE141
System-on-Chip
Test Architectures
39
Ch. 4 – SOC and NOC Testing - P. 39
Preferred TAM Widths
Testing time

Preferred
TAM width
Pareto-optimal
width

Only Pareto-optimal
TAM widths are
considered
Procedure: Tests are
scheduled at current
time in decreasing
order of preferred TAM
width until no TAM
width remains
TAM width
EE141
System-on-Chip
Test Architectures
40
Ch. 4 – SOC and NOC Testing - P. 40
Non-Preferred Rectangles: Fill Idle Time
Core 3
Next_time
Core 3
Core 3-P
Core 2-P
Core 2
Core 2-P
Core 1-P
Core 1-P
Core 1
Current_time
EE141
System-on-Chip
Test Architectures
41
Ch. 4 – SOC and NOC Testing - P. 41
Increasing Current TAM Widths
W_available
Core 4-P
Core 3
Core 3-P
Core 2-P
Core 1-P
 Modify
current
rectangle that will
benefit the most
from an increase
in TAM width
If idle time is inevitable,
advance Current_time and
repeat procedure from
the start
Current_time
EE141
System-on-Chip
Test Architectures
42
Ch. 4 – SOC and NOC Testing - P. 42
Current-Generation ATEs
• Port scalability features
• Digital speeds of up to 2.5 Gbps
• Application flexibility
Every port of a tester, consisting of multiple channels,
can configured at a desired data rate
EE141
System-on-Chip
Test Architectures
43
Ch. 4 – SOC and NOC Testing - P. 43
Virtual TAMs



Embedded core test frequency is limited by scan
frequency
 Scan frequencies are low to meet power,
routing, and clock skew constraints
Virtual TAMs allow use of high frequency ATE
pins
How can we match fast ATE data rates to slow
scan frequencies?
EE141
System-on-Chip
Test Architectures
44
Ch. 4 – SOC and NOC Testing - P. 44
Bandwidth Matching
High frequency
ATE
ATE lines
Bandwidth
Matching
10 low frequency
lines to the cores
Low frequency
ATE lines
ATE pins : WATE= 4
Virtual TAM
ATE frequency factor : n = 4
High frequency pins U = 2
U  f ATE  (WWW
U(f)nATE
fTAM
U nW
fTAM
fATE
1)W
TAM
U
TAM
TAM  (WATE  U )  fTAM
ATE
EE141
System-on-Chip
Test Architectures
45
Ch. 4 – SOC and NOC Testing - P. 45
Implementation of Bandwidth Matching
Low-speed TAM
SOC
Serial-In/
Parallelout
Registers
ATE
U
U
U
U
U
U
Embedded
core
U
U
Parallel-In/
Serialout
Registers
U
WATE -U
High-speed TAM
(n = 4)
Low-speed TAM
EE141
System-on-Chip
Test Architectures
46
Ch. 4 – SOC and NOC Testing - P. 46
Selection of U and n
 Testing
of SOC is often dominated by
the testing time of bottleneck cores
 Testing time of SOCs containing
bottleneck cores does not decrease for
TAM widths greater than W*
 The lower bound on test time in such
SOCs is T* corresponding to TAM
width W*
EE141
System-on-Chip
Test Architectures
47
Ch. 4 – SOC and NOC Testing - P. 47
SOCs with Bottleneck Cores
SOC
u226
d281
g1023
p34392
t512505
h953
f2126
q12710
EE141
System-on-Chip
Test Architectures
W* (bits)
48
48
40
36
36
16
16
16
cycles)
5333
3926
14794
544579
5228420
119357
335334
2222349
T* (clock
48
Ch. 4 – SOC and NOC Testing - P. 48
Relationship of U, n and W*

U and n should be chosen such that total
virtual TAM width W does not exceed W*
W W
*
W  nU  (WATE  U )
U (n  1)  W *  WATE
EE141
System-on-Chip
Test Architectures
49
Ch. 4 – SOC and NOC Testing - P. 49
Variation of U with n
EE141
System-on-Chip
Test Architectures
50
Ch. 4 – SOC and NOC Testing - P. 50
U vs n for ITC’02 Benchmarks
SOC p34392
SOC h953
W*=36
SOC d281
W*=48
EE141
System-on-Chip
Test Architectures
W*=16
SOC g1023
W*=40
51
Ch. 4 – SOC and NOC Testing - P. 51
Multiple-Speed TAM Architectures




Exploit port-scalability of ATEs
Facilitate efficient use of high data-rate tester channels
Unlike virtual TAMs, avoid on-chip hardware
overhead
Reduce testing time of bottleneck cores
I/O pads
fast
EE141
System-on-Chip
Test Architectures
slow
User-defined logic
I/O pads
Legacy
core
DSP
core
Interface
control
I/O pads
Memory
array
IP hard
core
ATE
Self-test
control
CPU
core
Embedded
DRAM
1149.1 TAP controller
SOC
52
Ch. 4 – SOC and NOC Testing - P. 52
Problem Formulation

Dual-speed optimization problem
Given:
f.r
V
ATE
r
SOC
Embedded
cores
W-V
Determine the wrapper design, TAM width and test data rate for each
core, and the SOC test schedule such that:
• the total number of TAM wires utilized at any moment does not exceed W
• the number of TAM wires driven at the high data rate does not exceed V
• the SOC testing time is minimized
EE141
System-on-Chip
Test Architectures
53
Ch. 4 – SOC and NOC Testing - P. 53
fast
r
Testing time
Testing time
Selection of Data Rate for a Core
f.r
TAM width
TAM width
Core 5 in SOC p93791
f =2
V=10
f =1 W-V=23
EE141
System-on-Chip
Test Architectures
T = 14026.9μs
T = 11398.9μs
54
Ch. 4 – SOC and NOC Testing - P. 54
Matching Core Scan Frequencies to ATE Data
Rates
Core A
Core B
Core C
Baseline
Case 1
TAM width
f = 40MHz
Core D
f = 80MHz
T = 456 μs
A
C
B
D
EE141
System-on-Chip
Test Architectures
w1= 8
f1= 40MHz
w2= 2, f2= 40MHz
Test time
55
Ch. 4 – SOC and NOC Testing - P. 55
Matching Core Scan Frequencies to ATE Data
Rates
Core A
Core C
Core B
Baseline
Case 2
TAM width
f = 40MHz
T = 275 μs
EE141
System-on-Chip
Test Architectures
f = 80MHz
C
A
Core D
D
B
w1= 8
f1= 80MHz
w1= 2, f2= 40MHz
Test time
56
Ch. 4 – SOC and NOC Testing - P. 56
Matching Core Scan Frequencies to ATE
Data Rates
Core A
Core B
Core C
TAM width
f = 40MHz
f = 80MHz
w1= 5
C
A
T = 246 μs
EE141
System-on-Chip
Test Architectures
B
Core D
f1= 80MHz
D
f2= 40MHz
w1= 5
Test time
57
Ch. 4 – SOC and NOC Testing - P. 57
Problem Statement
Given
 Test data parameters for N embedded cores
 Maximum scan frequency fi* for each core i
 SOC-level TAM width W
Determine
• The number of TAM partitions B
• Width wj and scan frequency fj of each TAM partition j
• Assignment of cores to TAM partitions
Such that
• TAM frequency does not exceed the maximum scan frequency of
any core assigned to that TAM partition
• The overall test time is minimized
• The sum of the widths of all the TAM partitions does not exceed W
EE141
System-on-Chip
Test Architectures
58
Ch. 4 – SOC and NOC Testing - P. 58
Solution Techniques



Lower bound on test time based on geometric
arguments (rectangle packing)
Integer linear programming
 Exact optimization method, limited to small
problem instances
Fast heuristic method
 Scalable, close to optimal results
EE141
System-on-Chip
Test Architectures
59
Ch. 4 – SOC and NOC Testing - P. 59
Comparison with Baseline
p22810
(5 frequencies: 10 to 50 MHz)
(X 100)
Test time (μs)
300
250
200
LB
baseline
proposed
37%
150
100
50
0
16
24
32
40
48
56
64
TAM Width
EE141
System-on-Chip
Test Architectures
60
Ch. 4 – SOC and NOC Testing - P. 60
Comparison with Exact Method and
Baseline
d695
(2 frequencies: 40 MHz and 50 MHz)
(X 100)
Test time (μs)
12
10
8
ILP
baseline
proposed
6
4
2
TAM Width
0
16
24
EE141
System-on-Chip
Test Architectures
32
40
48
56
64
61
Ch. 4 – SOC and NOC Testing - P. 61
Conclusions




Test reuse, test time minimization, and test compression
are necessary to reduce test cost for SOCs
Wrapper/TAM optimization and test scheduling can
reduce test time for core-based SOCs
Virtual TAMs offer several advantages for SOC testing
 On-chip TAM wires are not limited by the number of
available pins on the SOC
 Better utilization of high-speed ATE channels reduces
testing times
TAM architectures can match port-scalable ATE channels
to different scan frequencies of embedded cores
EE141
System-on-Chip
Test Architectures
62
Ch. 4 – SOC and NOC Testing - P. 62
Introduction to Network-On-Chip Testing




For future SoCs with large number of cores and
increased interconnect delay, traditional point-to-point or
bus-based communication architecture becomes new
bottleneck.
Traditional communication architectures cannot meet
system requirements of bandwidth, latency, and power
consumption.
Integrated switching network has been proposed as an
alternative approach to interconnect cores in SoC.
Such networks rely on a scalable and reusable
communication platform, called network-on-chip (NoC)
system, to meet two major requirements: reusability and
scalable bandwidth.
EE141
System-on-Chip
Test Architectures
63
Ch. 4 – SOC and NOC Testing - P. 63
Conceptual Architecture of a NoC System

The figure shown below represents a 2-D mesh NoC.
Core 1
Core 2
Router
Core 4
Router
Core 5
Router
Router
Core 3
Router
Core 6
Router
N bits



Cores are connected to NoC by routers or switches.
Data are organized by packets and transported through
interconnection links.
Various network topologies and routing algorithms can
be used to meet requirements of performance, hardware
overhead, power consumption.
EE141
System-on-Chip
Test Architectures
64
Ch. 4 – SOC and NOC Testing - P. 64
Special Features of NoC Testing




The greatest difference between NoC testing and SoC
testing is on test access mechanism design.
On-chip-network of a NoC can be reused as a TAM for
test packet delivery. Theoretically, no TAM interconnects
are required to be invested.
Test time can be reduced by network reuse even under
power constraints, with minimized pin count and area
overhead.
Generally, more cores can be tested in parallel than
TAM-based SoC testing, due to large NoC channel
bandwidth.
EE141
System-on-Chip
Test Architectures
65
Ch. 4 – SOC and NOC Testing - P. 65
Talk Outline for Testing Embedded Cores
in NoC

Reuse of On-Chip Network for Testing
Test Scheduling
Test Access Methods and Test Interface
Efficient Reuse of Network

Power-Aware and Thermal-Aware Testing



EE141
System-on-Chip
Test Architectures
66
Ch. 4 – SOC and NOC Testing - P. 66
Network-on-Chip
Current Design Methodology: System-on-Chip (SoC)
Interconnection schemes:
Memory
Array
Embedded RAM
IP Hard
Core
User Defined Logic
CPU
Self-test
Control
Core A
Core C
Shared bus
Interface
Control
EE141
System-on-Chip
Test Architectures
DSP
Core
Legacy
Core
Core B
Core D
Core A
Core C
Core B
Core D
Dedicated
connection
67
Ch. 4 – SOC and NOC Testing - P. 67
Need for Network-on-Chip (NOC)
Current Design Methodology: System-on-Chip (SoC)
Design
 Communication
infrastructure is becoming
new bottleneck
 Wire delay
 Signal integrity
 Power dissipation
 Area vs. speed
 New interconnection
schemes needed.
EE141
System-on-Chip
Test Architectures
Test
 Test of SoC has been well
understood
 TAM, wrapper
 Test scheduling
 IEEE 1500
 Test needs dedicated
hardware
 Hardware for missionmode communication can
not be reused for testing
68
Ch. 4 – SOC and NOC Testing - P. 68
NOC-based System
tester
SoC
core
core
core
core
core
core
EE141
System-on-Chip
Test Architectures
69
Ch. 4 – SOC and NOC Testing - P. 69
NOC-based System
Possible next-generation SoC paradigm:
Network-on-Chip (NoC)
Design
Test
 Test of NoC has not
 High performance
received much attention
 High bandwidth
 Low signal delay

 Core testing
 Router and interconnection
testing
 Test wrapper design
 Test scheduling
Reasonable overhead
 Suitable for large number
of cores
 Network design is versatile  No need for dedicated
TAMs
 Methodology of next
generation VLSI design
 Network can be reused for
70
testing
EE141
System-on-Chip
Test Architectures
Ch. 4 – SOC and NOC Testing - P. 70
NoC-based System
d695 from ITC’02
benchmark
1
router
5
router
10
router
Input
3
2
router
6
router
Input
9
router
router
4
router
8
router
EE141
System-on-Chip
Test Architectures
7
router
 Packet-switching
 Bidirectional channel
 2-D mesh, XY routing
Output  Channels, routers used
as TAM
 Input/output ports
router
associated with cores
Output  Ports, channels are
assigned a time tag
router
71
Ch. 4 – SOC and NOC Testing - P. 71
Test Scheduling Using Dedicated
Routing Path: Non-preemptive
1
router
5
router
10
router
Input
3
6
9
router
4
router
8
router
2
router
router
Input
router
router
7
router
EE141
System-on-Chip
Test Architectures
Output
Output
 Each core is associated
with a routing path
 All resources are
reserved until test
completed
 Test pipeline maintained
 No complex logic
 Similar to a circuit
switching
 Efficiently assign I/Os
and channels to core
router
72
Ch. 4 – SOC and NOC Testing - P. 72
Test Scheduling: Problem
Formulation
How to assign I/Os and channels to each core for testing such that
the overall test time is minimized?
In an NoC system using dedicated routing path, given NC cores, NI
inputs, NO outputs, routing algorithm and the network topology,
determine an assignment of cores to input/output pairs and a
schedule such that the total test time is minimized.
 Equivalent to the resource-constrained multi-processor scheduling
problem
 If the number of input/output pairs 2, NP-complete
EE141
System-on-Chip
Test Architectures
73
Ch. 4 – SOC and NOC Testing - P. 73
Test Scheduling: Optimal
Solution Using ILP
 Problem can be solved exactly using an ILP model
 Large number of none-zero constraints
 CPU time is prohibitive




Can be simplified using enumeration
Enumerate the assignment of cores to I/O pairs
Number of constraints reduced
A few seconds for small instances with smaller number of
I/Os
 For large instances, or larger number of I/Os, CPU time is still
prohibitively high
 Not suitable for large systems
EE141
System-on-Chip
Test Architectures
74
Ch. 4 – SOC and NOC Testing - P. 74
Test Scheduling: Heuristic
Algorithm
 Sort cores and I/O pairs in decreasing order of testing
time
 Permute cores and I/O pairs
 Assign cores with higher priority to free I/O pairs
 Check resource conflicts using time tag: I/Os, channels,
cores
 Complexity: O(NCM)
 CPU time: a few minutes for all benchmarks
EE141
System-on-Chip
Test Architectures
75
Ch. 4 – SOC and NOC Testing - P. 75
Test Access Method and Test
Interface
Problems targeted:
•
•
•
Test access scheme for testing routers at NoC level
Possible hardware overhead
Efficient test scheduling that can handle both routers
and embedded functional cores
EE141
System-on-Chip
Test Architectures
76
Ch. 4 – SOC and NOC Testing - P. 76
Test Access Method
Reuse the network resources for test access
Test data and test control delivered in packet
Responses can be processed by ATE or on-chip
3
4
5
5
5
6
2
3
4
4
4
6
Input
1
1
2
3
Outpu
t1
Input
1
1
2
3
Outpu
t1
Input
2
1
2
3
Outpu
t2
Input
2
1
2
3
Outpu
t2
Multicast
EE141
System-on-Chip
Test Architectures
Unicast
77
Ch. 4 – SOC and NOC Testing - P. 77
Test Responses
Can be handled on-chip
Wrapper
Wrapper
Wrapper
Wrapper
Router
Router
Router
Router
MISR
MISR
Minimum overhead
Probability of aliasing
EE141
System-on-Chip
Test Architectures
Comparator
Similar to prior work
Faster, with aliasing
78
Ch. 4 – SOC and NOC Testing - P. 78
Test Wrapper
On top of the 1500 compliant wrapper
Can wrap both router and core
Packing/unpacking mechanism reused from mission mode
1500 compliant
From
adjacent
cores
Router
pack
ing
Unpack
ing
Core
To
adjacent
cores
Test mode
EE141
System-on-Chip
Test Architectures
79
Ch. 4 – SOC and NOC Testing - P. 79
Test Wrapper
To
adjacent
cores
From
adjacent
cores
Unpack
ing
pack
ing
Router
Core
Mission mode
EE141
System-on-Chip
Test Architectures
80
Ch. 4 – SOC and NOC Testing - P. 80
Integrated Test Scheduling
Based on network reuse and dedicated routing path
 Permute cores in the order of test time
 Permute all input/output pairs
 For each permutation
 Find free I/O pair
 Check for resource conflicts
 schedule a core
 Routers on a path should be all tested before functional cores on
that path to be tested
 Routers can be tested concurrently with cores
 At least one I/O pair should be used for router testing at any time
EE141
System-on-Chip
Test Architectures
81
Ch. 4 – SOC and NOC Testing - P. 81
Integrated Test Scheduling
3
4
5
6
7
8
2
3
4
4
5
9
Input
1
1
2
3
Output
1
Input
1
1
2
3
Output
1
Input
2
1
2
3
Output
2
Input
2
1
2
3
Output
2
After these routers are tested, one of the two I/O pairs can be
used for core testing
EE141
System-on-Chip
Test Architectures
82
Ch. 4 – SOC and NOC Testing - P. 82
Efficient Channel Width Utilization
Fixed channel width, not fully utilized
Channel width = 16
Channel width = 32
Cores
# of packets
flits/packet
test cycles
flits/packet
test cycles
1
24
2
38
1
25
2
146
13
1029
7
588
3
150
32
2507
32
2507
4
210
54
5829
54
5829
5
220
109
12192
55
6206
6
468
50
11978
41
9869
7
190
43
4219
34
3359
8
194
46
4605
46
4605
9
24
128
1659
64
836
10
136
109
7568
55
3836
EE141
System-on-Chip
Test Architectures
83
Ch. 4 – SOC and NOC Testing - P. 83
Utilization of Idle Channel Width
Variable on-chip test clocks
 Use faster wrapper test clocks on cores with idle channel
width
 Channel width w, wrapper scan chain w’, n flits can be
transported in parallel to core in one clock
w
n =  w’ 
 Additional cores can be selected to further reduce test
time
EE141
System-on-Chip
Test Architectures
84
Ch. 4 – SOC and NOC Testing - P. 84
Utilization of Idle Channel Width
Slower tester clock
Tester
Test data
faster on-chip clock
PLL
wrapper
wrapper
4
Core
A
router
router
NoC
EE141
System-on-Chip
Test Architectures
4
Core
B
Network
channel
85
Ch. 4 – SOC and NOC Testing - P. 85
Channel Width Utilization
Under Power Constraints
Variable on-chip test clocks
 Use slower wrapper test clocks on cores with high power dissipation
 No change on wrapper design
 Physical channel is viewed as n virtual channels
Tester clock
Packets in channel
A
B
C
A
B
C
Test clock on core A
Test clock on core B
Test clock on core C
EE141
System-on-Chip
Test Architectures
86
Ch. 4 – SOC and NOC Testing - P. 86
Power-Aware Test Scheduling
Variable on-chip test clocks in NoC-based system
 N cores, tester clock fT
 Faster on-chip clocks 2fT, 3fT, …
 Slower on-chip clocks fT /2, fT /3, …
 Determine a clock for each core, such that
No network resource conflicts
System test application time is minimized
Power constraints are not violated
EE141
System-on-Chip
Test Architectures
87
Ch. 4 – SOC and NOC Testing - P. 87
Power-Aware Test Scheduling
 Each core associated with a set of on-chip clocks {…3fT, 2fT,
fT, fT /2, fT /3, …}
 Each clock corresponds to a power P(i,j), and the
corresponding test time T(i,j)
 Selection of clock for each core controlled by a priority
calculated from P/T
 More than one cores use slower clocks to utilize virtual
channels
 Use dedicated routing path
 Power constraints are evaluated
EE141
System-on-Chip
Test Architectures
88
Ch. 4 – SOC and NOC Testing - P. 88
Thermal-Aware Test Scheduling
High power density causes hot spots
30w
9w 8w
• Existence of hot spots may increase test
time because of thermal unbalance
• Layout redesign is impossible
10w
5w
• Layout not optimized for test
• Higher power generation
10w 8w
5w
40w 55w 15w
5w 13w 18w
• Larger thermal variation
• Removal of hot spots can lead to thermal
balance and reduced test time
EE141
System-on-Chip
Test Architectures
89
Ch. 4 – SOC and NOC Testing - P. 89
Variable Clocking in Test Session
•
•
•
•
•
Still rely on using multiple variable clocking for thermal
management
Clock assigned to each core can be varied during test
application
A more flexible scheme
More efficient thermal management
Extra test control
EE141
System-on-Chip
Test Architectures
90
Ch. 4 – SOC and NOC Testing - P. 90
Variable Clocking in Test
Session
Clock
Clock
Core 1
Core 1 Core 3
Core 3
Core 2
Time
Core 2
t1
Time
t2
<
t2
t1
Thermal safe constraints are not violated
Test time reduced
EE141
System-on-Chip
Test Architectures
91
Ch. 4 – SOC and NOC Testing - P. 91
Variable Clocking in Test
Session
Clock
Core 1
Clock
Core 3
Core 1 Core 3
Core 2
Core 2
Time
t3
Time
t3
=
t4
t4
Thermal safe constraints guaranteed
Test time not compromised
EE141
System-on-Chip
Test Architectures
92
Ch. 4 – SOC and NOC Testing - P. 92
Clock Selection
Clock
PLL
f/4 f/2
f
2f
4f
Test
packet
Router
Unpack
Core
Unpack reused
Test control can be carried in packet
Clock varies only when the test of a core finished or started
EE141
System-on-Chip
Test Architectures
93
Ch. 4 – SOC and NOC Testing - P. 93
Problem Formulation
 Test set information of core set C
 NC cores, NI inputs, NO outputs,
 Set of on-chip variable-rate clock CLK
 Set of thermal parameters Pthermal
 Chip floorplan, and maximum temperature TTH
 Determine: (1) clock variation of each core during test
application, (2) test scheduling of cores on I/Os and
channels, such that:
Test application time is minimized
Maximum temperature not over TTH
EE141
System-on-Chip
Test Architectures
94
Ch. 4 – SOC and NOC Testing - P. 94
Talk Outline for On-Chip Network
Testing




Testing of interconnect infrastructures [Grecu 2006]
Testing of routers [Amory 2005]
Testing of network interfaces and integrated
system testing [Stewart 2006]
Unless on-chip network of an NoC has been
completely tested, it cannot be used to test the
embedded cores.
EE141
System-on-Chip
Test Architectures
95
Ch. 4 – SOC and NOC Testing - P. 95
Testing of Interconnect Infrastructures





Interconnect testing has been discussed in many
.
papers.
This discussion is mainly based on the well-known
maximal aggressor fault (MAF) model.
Apply identical transitions to all wires except the victim
line to create maximal integrity loss in the victim line.
Contains six crosstalk errors in victim line: rising/falling
delay, positive/negative glitch, and rising/falling speedup.
For an interconnect structure with N lines, totally 6N
faults are to be tested using 6N two-vector test patterns.
EE141
System-on-Chip
Test Architectures
96
Ch. 4 – SOC and NOC Testing - P. 96
Self-Test Structure
A pair of test data generator (TDG) and test error
detector (TED) is inserted to each set of interconnects
between two routers (switches).
switch
TDG



TEG
switch

This is called point-to-point MAF self-test.
Test patterns are launched before line drivers, and
sampled after receiver buffers.
Highly parallel testing if power consumption is within
the power budget.
EE141
System-on-Chip
Test Architectures
97
Ch. 4 – SOC and NOC Testing - P. 97
Test Application by Unicast

MAF test patterns can be broadcast to all
interconnects by test packets with only one TDG.
TED
GTC
GTC
TED
TED
TED
TED
TED
TED
TED
TED
TED
TED

TED
TDG
TED

TED
TDG
Only one set of interconnects between a pair of
routers can be tested for each test pattern broadcast.
A global test controller (GTC) and many TEDs are
required.
EE141
System-on-Chip
Test Architectures
98
Ch. 4 – SOC and NOC Testing - P. 98
Test Application by Multicast

Test packets are broadcast to interconnects of different pairs
of routers to achieve maximum parallelism.
TED
GTC
GTC
TED
TED
TED
TED
TED
TED
TED
TED
TED
TED

TED
TDG
TED

TED
TDG
Multicast is a good compromise between test application
time and hardware overhead.
Point-to-point (unicast) test method has the smallest
(largest) test application time but the largest (smallest)
hardware overhead.
EE141
System-on-Chip
Test Architectures
99
Ch. 4 – SOC and NOC Testing - P. 99
Testing of Routers
Routers are used to implement functions of flow control,
routing, switching and buffering of packets.
core
1
NoC
core
6
interfaces
Primary inputs of the Chip
System-on-Chip
R
R
R
R
R
R
core
2
core
5
core
3
channels
routers
Primary outputs of the Chip

core
4


Router testing can be treated as sequential circuit
testing by taking its special property of regularity.
Test pattern broadcasting can be applied to reduce test
time.
EE141
System-on-Chip
Test Architectures
100
Ch. 4 – SOC and NOC Testing - P. 100
Testing A Router

Testing a router consists of testing the control logic
(routing, arbitration, and flow control modules) and first-in
first-out (FIFO) buffers.
Primary inputs of the Router
input port


IP
FIFO
OP
IP
FIFO
FIFO
OP
switch
IP
OP
OP
FIFO
IP
routing/
arbitration
output
port
Primary outputs of the Router
IOs of the NoC and the Router
Local port
Control logic can be tested by typical sequential circuit
testing methods such as scan testing.
A smart way to test FIFO is to configure the first register of
FIFO as scan register, and others can be tested by the
scan register.
EE141
System-on-Chip
Test Architectures
101
Ch. 4 – SOC and NOC Testing - P. 101
Testing All Routers

Since all routers are identical, all can be tested in parallel
by test pattern broadcasting.
router 0
router 1
SI0
=
router 2

NoC
router 3
SO0
Se0..4
Comparator is implemented by XOR gates. It can also
support diagnosis.
EE141
System-on-Chip
Test Architectures
102
Ch. 4 – SOC and NOC Testing - P. 102
Router Test wrapper Design and Test

IEEE-1500 compliant test wrapper is designed to support
test pattern broadcasting and test response evaluation.
modifications required for the test wrapper
se[0..r]
NoC
diagnosis
control block
router 0
sc1 [0:n]
Si[0:2]
=
sc0 [0:m]
20
=
router n
ci0
So[0:2]
=
co0
sc1 [0:n]
=
sc0 [0:m]
co19
[0]
Dout_R0
[0:19]
functional ports router 0
[19]
[19]
[0]
[0]
Din_Rn
[0:19]
Dout_Rn
[0:19]
functional ports router n
[19]
...
...
Functional inputs
[0]
Din_R0
[0:19]
Functional outputs
ci19
[19]
control ports
special_in
EE141
System-on-Chip
Test Architectures
test wrapper
103
Ch. 4 – SOC and NOC Testing - P. 103
Router Test Wrapper Design and Test (Contd.)





For example, all SC1 chains of these routers share the
same set of test patterns.
Similarly, all Din[0] (i.e., Din-R0[0], …, Din-Rn[0]) data
inputs of these routers share the same set of test
patterns.
The wrapper also supports test response comparison for
scan chains and data outputs.
Diagnosis control block can activate diagnosis.
Small hardware overhead (about 8.5%) and small number
of test patterns (several hundreds) due to test
broadcasting. Small test application time (several
thousands test cycles) using multiple, balanced scan chain
and test broadcasting. The method is scalable.
EE141
System-on-Chip
Test Architectures
104
Ch. 4 – SOC and NOC Testing - P. 104
Network Interface Testing




Network interface (NI) is used to receive data bits from
its corresponding IP core (router), packetize (depacketize) the bits, and perform clock domain
conversions between the router and the core.
NI might be the most difficult to test component in an
on-chip network, because clock domain conversion
introduces non-deterministic device behavior.
Current test methods rely on deterministic stored
responses.
The following discussion mainly based on functional
test method, though new structural test solutions must
be developed soon.
EE141
System-on-Chip
Test Architectures
105
Ch. 4 – SOC and NOC Testing - P. 105
A NI Functional Test Model

The NI of AEthereal NoC architecture.
Multicast
Controller
M-Controller
Buffers
Narrowcast
Controller
S-Controller
Buffers
NI Kernel
Aethereal NI

Master-controller (IP masters initiate transactions by
issuing requests); slave-controller (IP slaves receive
and execute transactions); multicast connection (one
master, multiple slaves, all slaves executing each
transaction); narrowcast connection (one master,
multiple slaves, a transaction executed by only one
slave).
EE141
System-on-Chip
Test Architectures
106
Ch. 4 – SOC and NOC Testing - P. 106
NI Functional Fault Representation

NI faults in AEthereal can be represented with four-tuple
NI(c1, c2, o1, o2) where c1: ID of NI under test, c2:
whether the NI under test is a source (S) or destination (D),
o1: transmission mode (BE or GT) of NI, o2: connection
type (U, N, M) of NI.

Notation: BE – best effort, GT – time guarantee, U –
unicast, N – narrowcast, M – multicast. Note that o1 and o2
are optional.

Each NI must be tested based on different combinations of
these tuples.
EE141
System-on-Chip
Test Architectures
107
Ch. 4 – SOC and NOC Testing - P. 107
Number of Functional Faults





For each NI represented by NI(ID, c2, o1, o2), it must be
tested as a source (master) and as a destination (slave).
In each case, the NI must be tested with both BE and GT
transmission modes. So, four faults must be considered.
Two additional tests are required to test narrowcast (N)
and multicast (M) for the NI. Totally, six faults must be
dealt with for thoroughly testing each NI.
Unicast (U) is not required to be added, because it has
been applied during the first four faults.
By following the same process, ten functional faults can
be identified for each router.
Test patterns must be generated to detect all six (ten)
faults for each NI (router).
EE141
System-on-Chip
Test Architectures
108
Ch. 4 – SOC and NOC Testing - P. 108
Test Scheduling for Functional testing





It is important to develop an efficient method that can
generate test patterns shared for NI faults and router
faults.
Initially, a preprocessing step is used to broadcast
data packets (GT data and BE data) from I/O pins to
local memory of each core.
During test phase, an instruction packet is sent from
input port of the NoC to the source router by GT
transmission mode.
Instruction packet contains information of destination
core, transmission path, time at which test pattern
application should take place.
Destination node generates a signature packet.
EE141
System-on-Chip
Test Architectures
109
Ch. 4 – SOC and NOC Testing - P. 109
Notes for NoC Functional Testing

Functional testing for NI is not sufficient, and efficient
structural test methods must be investigated.

Testing NoC-based system by separating core testing
from on-chip network testing is inadequate.

Interactions between cores and on-chip network must be
tested using extensive functional testing.

Interactions between on-chip network components
(routers, interconnects, and NIs) must be thoroughly
tested by functional testing as well.
EE141
System-on-Chip
Test Architectures
110
Ch. 4 – SOC and NOC Testing - P. 110
Talk Outline for Design and Test
Practices


SoC testing for PNX8550 system chip [Goel 2004].
NoC testing for high-end TV system [Steenhof 2006].
EE141
System-on-Chip
Test Architectures
111
Ch. 4 – SOC and NOC Testing - P. 111
Case Study: Soc Testing for PNX8550
System Chip






PNX8550 is a chip designed based on Nexperia
digital video platform by NXP [Goel 2004].
Fabricated using 0.13um process, six metal layers,
with 1.2V supply voltage.
Entire chip contains 62 logic cores (5 hard, 57 soft),
212 memory cores, and 94 clock domains.
Five hard cores: one MIPS CPU, two TriMedia
CPUs, a custom analog block (PLLs and DLLs), and
a D-to-A converter.
All 62 logic cores are partitioned into 13 chiplets.
Each chiplet is a group of cores placed together, and
is connected to a specific set of TAM wires.
EE141
System-on-Chip
Test Architectures
112
Ch. 4 – SOC and NOC Testing - P. 112
Structure of PNX8550

Nexperia home platform
SDRAM
MMI
IP MODULE
SOC
EE141
System-on-Chip
Test Architectures
TM-Device Control & Status Network
IP MODULE
MEMORY ACCESS NETWORK
IP MODULE
MIPS-Device Control & Status Network
MIPS CPU
D$
PRxxxx
I$
TriMedia CPU
D$
TMxxxx
I$
IP MODULE
IP MODULE
IP MODULE
Bridge
113
Ch. 4 – SOC and NOC Testing - P. 113
PNX8550 Structure and Test Methods






Two device control and status (DCS) networks enable each
processor to observe on-chip modules.
A bridge is used to allow both DCS networks to
communicate.
Soft logic cores include MPEG decoder, UART, PIC 2.2 bus
interface, etc.
CPUs and many modules have access to external memory
via a high-speed memory access network.
PNX8550 allows test reuse through test wrappers
(TestShell), and test access mechanism (TestRail).
Test methods: random logic – full scan test with 99% stuckat fault coverage, small embedded memories – scan test,
large memories – BIST.
EE141
System-on-Chip
Test Architectures
114
Ch. 4 – SOC and NOC Testing - P. 114
PNX8550 Test Strategies





There are 140 TAM wires (i.e., 280 chip pins) for the
entire chip.
Design issue: how to assign these TAM wires to
different cores and how to design the wrapper for
each core.
Requirement: each channel must provide 28M of test
data volume and test application time must be
minimized.
NXP developed a tool called TR-ARCHITECT to deal
with these core-based testing requirements.
TR-ARCHITECT supports three test architectures:
daisy chain, distribution, and hybrid (of daisy chain
and distribution).
EE141
System-on-Chip
Test Architectures
115
Ch. 4 – SOC and NOC Testing - P. 115
TR-ARCHITECT Inputs

Requires two different kinds of inputs: SoC data file and
a list of user options.

SoC data file: SoC parameters such as number of cores
in the SoC, number of test patterns and number of scan
chains in each core.

User options: test choices such as number of SoC test
pins, type of modules (hard or soft), TAM type (test
bus/test rail), architecture type (daisy chain, distribution,
or hybrid), test schedule type (serial or parallel for daisy
chain), and external bypass per module (yes/no).
EE141
System-on-Chip
Test Architectures
116
Ch. 4 – SOC and NOC Testing - P. 116
TAM Wires Distribution and Test Architecture





Distribution of 140 TAM wires to 13 chiplets is done
manually, because TR-ARCHITECT became available half
way of PNX8550 design process.
Assignment of TAM wires for a chiplet ranges from 2 to 21.
Next step is to design the test architecture inside each
chiplet.
Distribution test architecture is used for all except two
chiplets: UMDCS and UTDCS.
For these two chiplets (hybrid test architecture), some wires
are shared by two or more cores using daisy chain; some
cores are connected by distribution architecture.
EE141
System-on-Chip
Test Architectures
117
Ch. 4 – SOC and NOC Testing - P. 117
Test Architecture Design for Each Chiplet



Test architecture design is trivial if chiplet under
consideration has only one core. Test wrapper of the core
can be designed based on TAM wires assigned and core
parameters.
For a chiplet containing multiple cores and using
distribution test architecture, TR-ARCHITECT determines
the number of TAM wires assigned to each core and
design the test wrapper for the core.
For both chiplets with hybrid test architecture, TRARCHITECT determines the number of TAM-wire groups,
the width assigned to each group, assignment of cores to
each group, and design the test wrapper for each core.
EE141
System-on-Chip
Test Architectures
118
Ch. 4 – SOC and NOC Testing - P. 118
TR-ARCTITECT Major Procedures





There are four major steps: create-start-solution,
optimize-bottom-up, optimize-top-down, reshuffle.
Create-start-solution: assign at least one TAM wire for
each core.
If there are cores left unassigned, they are assigned to
least occupied TAMs.
If there are TAM wires left unassigned, they are added to
the most occupied TAMS.
Optimize-bottom-up: merge the TAM (maybe several
wires) with shortest test time with another TAM, such that
wires free up in this process can be used for overall test
reduction.
EE141
System-on-Chip
Test Architectures
119
Ch. 4 – SOC and NOC Testing - P. 119
Example for Optimize-bottom-up







TAM-1 has three wires with 500 test cycles for Core-1.
TAM-2 has four wires with 200 test cycles for Core-2.
TAM-3 has two wires with 100 test cycles for Core-3.
Core-1 is the test bottleneck and number of total test
cycles is 500.
Merge Core-3 to TAM-2, and number of overall test
cycles for Core-2 and Core-3 is 300 (by assumption), still
smaller than 500.
Two wires freed up by TAM-3 can be added to TAM-1 to
reduce number of Core-1 test cycles from 500 to 350 (by
assumption).
Finally, number of overall test cycles can be reduced
from 500 to 350.
EE141
System-on-Chip
Test Architectures
120
Ch. 4 – SOC and NOC Testing - P. 120
TR-ARCHITECT Major Procedures and Results




Optimize-top-down and Reshuffle follow the same idea
and can be found in [Goel 2002].
Each of the four procedures requires information of
wrapper design and test time for each assignment of
TAM wires, which can be provided by [Marinissen 2000].
By manually assigning 140 TAM wires to 13 chiplets,
total test time is dominated by UTDCS with 3,506,193
test cycles.
If these 140 TAM wires are distributed to 13 chiplets by
TR-ARCHITECT and hybrid test architecture is used,
total test time is reduced to 2,494,687 test cycles
(dominated by UMCU). Note: UTDCS is assigned three
more TAM wires by TR-ARCHITECT, and changed to be
non-dominant.
EE141
System-on-Chip
Test Architectures
121
Ch. 4 – SOC and NOC Testing - P. 121
Case Study: NoC Testing for High-End TV
Companion Chip by NXP

The following figure outlines a high-end TV system with
two chips: main chip (PNX8558 discussed above), and
companion chip (implementing more advanced
technologies that will not be released to competitors)
[Steenhof 2006].
memory
memory
Companion chip
Main chip
in
I
I
Interconnect
O
out
EE141
System-on-Chip
Test Architectures
H
Interconnect
HSEL
O
C
122
Ch. 4 – SOC and NOC Testing - P. 122
Main TV Chip and Companion Chip




Main TV chip (PNX 8550 discussed in SoC testing case
study) controls entire system and interacts with users, TV
sources, TV display, peripherals, and configuration of
companion chip.
Companion chip contains nine IP blocks for enhancing
video quality.
Main and companion chips have their own dedicated
interconnect structures. They are connected using a highspeed external link (HSEL).
Idea of partitioning a complex system into main and
companion chips has many advantages: reducing
development risk, managing different innovation rates in
different market segments, encapsulating different
functionality.
EE141
System-on-Chip
Test Architectures
123
Ch. 4 – SOC and NOC Testing - P. 123
System Tasks


Functionality of whole system contains several
hundreds of tasks controlled by main chip.
Dash lines in following figure represent a task
involving 11 IP blocks in main, companion chips and
two memories. Notation: I (input), O (output), H
(horizontal scaler), C (control processor).
memory
memory
Main chip
in
Companion chip
I
I
Interconnect
O
H
Interconnect
HSEL
O
C
out
EE141
System-on-Chip
Test Architectures
124
Ch. 4 – SOC and NOC Testing - P. 124
Companion Chip - NoC Implementation

On-chip network of companion chip contains routers (R),
interconnects, and network interface (NI). Each NI contains
one kernel (K), one shell (S), and several ports. Mainly, it is
a 2x2 mesh NoC.
4M,4S
S K
1M
C
MSEL
IO
2M,2S
S K
R
R
K S
S K
R
R
K S
1M,2S
2M,2S
1M,2S
NB1
K S
K S
S
K
2M,1S
New
HSEL
2M,2S
NB2
H
2M,2S
EE141
System-on-Chip
Test Architectures
1M,1S 1M,1S
125
Ch. 4 – SOC and NOC Testing - P. 125
Companion Chip - NoC Implementation (Contd.)


Numbers of master (M) and slave (S) ports are indicated
in each NI.
Ports are connected to IPs of microprocessors, DSPs,
or memory arrays. New HSEL is used to attach another
companion chip (e.g., FPGA).
4M,4S
S K
1M
C
MSEL
IO
2M,2S
S K
R
R
K S
S K
R
R
K S
1M,2S
2M,2S
1M,2S
NB1
K S
K S
S
K
2M,1S
New
HSEL
2M,2S
NB2
H
2M,2S
EE141
System-on-Chip
Test Architectures
1M,1S 1M,1S
126
Ch. 4 – SOC and NOC Testing - P. 126
Test Methods for NXP AEthreal NoC





Test methods for NXP AEthreal NoC architecture can be
found in [Vermeulen 2003].
On-chip network can be treated as a core for testing.
Knowledge about on-chip network can be used to enhance
standard core-based test approach to get better results. For
example, routers can be tested by test broadcasting, while
test responses can be compared to each other.
Timing test is extremely important because: (1) long wires in
NoC may cause crosstalk errors, and (2) clock boundaries
between cores are in NIs and timing errors can occur.
Long wire testing can be dealt with by [Grecu 2006], but point
(2) is still waiting for good solution.
EE141
System-on-Chip
Test Architectures
127
Ch. 4 – SOC and NOC Testing - P. 127
Test Methods for NXP AEthreal NoC
(Contd.)
 Once
on-chip network has been fully
tested, it can be used to transfer data
for core testing.
 No TAM wires are required for testing,
and NoC is fully reused for core testing.
 NoC structure also supports parallel
testing if channel capacity can support
parallel data transportation with a
specific power budget.
128
EE141
System-on-Chip
Test Architectures
Ch. 4 – SOC and NOC Testing - P. 128
Concluding Remarks





State-of-art techniques for SoC testing have been
described.
Modular test techniques for digital, mixed-signal, and
hierarchical SoCs must be developed further to keep pace
with technology advances.
Test data bandwidth needs for analog cores are very
different from digital cores, and unified top-level testing of
mixed-signal SoCs remains a major challenge.
Research is also needed to develop wrapper design
techniques and test planning methods for multi-frequency
core testing.
Revolutionary RF interconnect technology might emerge
to address future SoC testing.
EE141
System-on-Chip
Test Architectures
129
Ch. 4 – SOC and NOC Testing - P. 129
Concluding Remarks (Contd.)





Advances in testing NoC-based systems have been
discussed.
Key point: how to utilize on-chip network as a TAM
without compromising fault coverage or test time.
Research on NoC testing is still premature when
compared to industrial needs, and future research and
development are needed.
Wrapper design techniques for SoC testing can be
adopted by NoC-based systems.
Case studies for SoC testing and NoC testing have been
provided to demonstrate efforts in testing real-world SoC
and NoC designs.
EE141
System-on-Chip
Test Architectures
130
Ch. 4 – SOC and NOC Testing - P. 130