system/network -on -chip test...
TRANSCRIPT
EE141
1System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 1
Chapter 4Chapter 4
System/NetworkSystem/Network--onon--ChipChip
Test ArchitecturesTest Architectures
EE141
2System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 2
What is this chapter about?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
3System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 3
Introduction to Introduction to SoCSoC TestingTesting� 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
4System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 4
Challenges of Challenges of SoCSoC TestingTesting� 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 user-defined 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
5System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 5
Conceptual Architecture of Embedded CoreConceptual Architecture of Embedded Core--
Based Based SoCSoC TestingTesting
� Mainly, three structural elements are required. They are
test pattern source and sink, test access mechanism
(TAM), and core test wrapper.
EE141
6System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 6
More Test Challenges 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
7System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 7
Talk Outline for Talk Outline for SoCSoC TestingTesting� 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
8System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 8
System ChipsSystem Chips
1 cm~50 million transistors
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
9System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 9
Motivation for Testing: Motivation for Testing: XBoxXBox 360 360
Technical ProblemsTechnical 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
10System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 10
XBoxXBox 360 Technical Problems (Cont360 Technical Problems (Cont’’d)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
11System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 11
Testing Principles (2Testing Principles (2--minute primer)minute primer)
• Screen defective chips (wafer, package)
• Stress test (burn-in)• Diagnosis: Locate defects,
yield learning
• Speed binning• Design-for-testability (DFT)
typically used• Test generation, scan design
EE141
12System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 12
� 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
Motivation for CoreMotivation for Core--Based SOC TestingBased SOC Testing
ITRS’03
Test cost
Manufacturing
cost
EE141
13System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 13
SystemSystem--onon--Chip (SOC)Chip (SOC)
I/O pads
I/O
pa
ds
I/Op
ad
s1149.1 TAP controller
Us
er-
de
fin
ed
log
ic
CPUcore
Self-testcontrol
Legacycore
IP hardcore
DSPcore
Memoryarray
Interfacecontrol
EmbeddedDRAM
• Test access is limited• Test sets must be transported to embedded logic
• High test data volume & test time
Philips Philips NexperiaNexperiaTMTM PNX8550 SOC: 338,839 PNX8550 SOC: 338,839 flipflip--flops, 274 embedded cores, 10M logic gates, 40M logic transistorflops, 274 embedded cores, 10M logic gates, 40M logic transistors!s!
EE141
14System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 14
Cost of TestCost 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
15System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 15
Modular TestingModular 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]
Wrapper
Embedded
core
SOC
TAM TAM
Automatic Test Equipment (ATE)
Embedded
coreEmbedded
core
EE141
16System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 16
Test Planning
Optimizing Test Access to Cores and Scheduling Test Hardware
Core import
Core integration
Test wrapper& TAM design
Top-level DFT•Test control blocks•IEEE 1149.1
Test hardware planning
Core test import
Test assembly
Test scheduling
Top-level ATPG•Glue logic, soft cores•Test wrappers
Test software planning
EE141
17System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 17
IEEE 1500 Core Test StandardIEEE 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
18System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 18
IEEE 1500 WrapperIEEE 1500 Wrapper
Wrapper Modes: (1) Normal; (2) Serial Test; (3) 1-N Test; (4) Bypass; (5)
Isolation; (6) Extest [Marinissen 2002]
EE141
19System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 19
Wrapper Boundary CellsWrapper Boundary Cells
EE141
20System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 20
Wrapper UsageWrapper Usage
EE141
21System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 21
Wrapped Embedded CoresWrapped Embedded Cores
EE141
22System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 22
Wrapper Operation Modes (I)Wrapper Operation Modes (I)
Normal Mode Serial Bypass Mode
EE141
23System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 23
Wrapper Operation Modes (II)Wrapper Operation Modes (II)
Serial Internal Test Mode Serial External Test Mode
EE141
24System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 24
Wrapper Operation Modes (III)Wrapper Operation Modes (III)
Parallel Internal Test Mode Parallel External
EE141
25System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 25
Test Wrapper OptimizationTest Wrapper Optimization
4 FF
8 FF
Wrapper
Core
Unbalanced
4 FF
8 FF
Wrapper
Core
Balanced
Minimize length of longest wrapper scan in/out chain
Priority 1: Balanced Wrapper Scan Chains
EE141
26System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 26
Reducing TAM WidthReducing TAM Width
Scan chain – 32 FF
8 FF
8 FF
8 FF
I
I
I
I O
O4 Wrapper scan chains
Scan chain – 32 FF
I I I I 8 FF O O8 FF 8 FF
2 Wrapper scan chains
Priority 2: Minimize wrapper scan chains created
EE141
27System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 27
TwoTwo--Priority Wrapper Design AlgorithmPriority Wrapper Design Algorithm
1. Minimize length of longest wrapper scan in/out chain
2. Minimize number of wrapper scan chains
TAM widthLon
gest
wra
pp
er
scan
chain
Design_wrapper algorithm uses
the BFD heuristic for Bin Design
EE141
28System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 28
Test Access MechanismsTest Access Mechanisms
� 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]
C1 C2 C3Multi-plexed
C1 C2 C3 Distri-bution
Types of TAMs
C1 C2 C3 Daisy-chain
EE141
29System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 29
Test Bus ArchitectureTest Bus Architecture
A B
C D E
F
SOCSOC
Architecture
AA
→→→→→→→→ test timetest time→→ →→→→ →→
TA
M w
idth
TA
M w
idth
BB
CC DD EE
FF
Schedule: Serial
� Combination of multiplexing and distribution
� Supports only serial schedule
� Core-external testing is cumbersome or impossible
EE141
30System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 30
TestRailTestRail Architecture Architecture [[GoelGoel ITCITC’’02]02]
� Combination of Daisychain 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
C1 C2 C3
Fixed-width TestRails
C1 C2
w1
w2
C1 C2 C3
Flexible-width TestRails
C1 C2
W
EE141
31System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 31
Wrapper Wrapper Wrapper
IP IP IP
StepStep--byby--Step Approach to Wrapper/TAM Step Approach to Wrapper/TAM
CoCo--optimizationoptimization
W3
W1
W2 TAMs
4. PNPAW: Number of TAMs + PPAW
3. PPAW: TAM width partitioning + PAW
2. PAW: Core assignment + PW
1. PW: Wrapper design
EE141
32System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 32
Mathematical Programming Model for Mathematical Programming Model for
TAM PartitioningTAM 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
33System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 33
TAM Design and Test SchedulingTAM 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
34System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 34
Architectures Determine SchedulesArchitectures Determine Schedules
[Goel ’03] Slide provided by Erik Jan Marinissen, Philips Research Labs
EE141
35System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 35
Rectangle Model for Test BusesRectangle Model for Test Buses
Core 1 Core 3 Core 9 Core 8
Core 2 Core 4
Core 5 Core 6 Core 7
Three test busesEach core on same bus gets equal, fixed TAM width
Bus 1
Bus 2
Bus 3
EE141
36System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 36
Test SchedulingTest Scheduling
� 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
Core 1
Core 2 Core 4
Core 5
Time
Sche
du
le
Idle bits
EE141
37System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 37
Rectangle RepresentationRectangle 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
Collection R
Ti(wj)
wj
Set Ri of rectanglesfor Core i
EE141
38System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 38
Rectangle Packing ProblemRectangle 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
Collection R
Core 2
Core 1
Core 3
Height
Width
EE141
39System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 39
Packed Bin = TAM Design + Test SchedulePacked Bin = TAM Design + Test Schedule
Core 1
Core 2
Core 3
Core 8
Core 4
Core 6
Core 7
Core 5
Bin
heig
ht
=
tota
l T
AM
wid
th
Bin width = SOC testing time
Empty space = wasted tester memory
Rectangle area = tester memory for core test
EE141
40System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 40
Preferred TAM WidthsPreferred TAM Widths
� Only Pareto-optimalTAM widths are considered
� Procedure: Tests are scheduled at current time in decreasing order of preferred TAM width until no TAM width remains
TAM width
Testing time
PreferredTAM width
Pareto-optimal width
EE141
41System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 41
NonNon--Preferred Rectangles: Preferred Rectangles: FillFill Idle TimeIdle Time
Core 1-P
Core 2-P
Core 1
Core 2
Core 3
Core 1-P
Core 2-P
Core 3
Core 3-P
Next_time
Current_time
Tot a
l T
AM
wid
th
EE141
42System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 42
Increasing Current TAM WidthsIncreasing Current TAM Widths
�Modify current rectangle that will benefit the most from an increase in TAM width
Core 1-P
Core 4-PCore 3-P
Current_time
Tot a
l T
AM
wid
th
Core 2-P
Core 3
W_available
If idle time is inevitable, advance Current_time and repeat procedure from the start
EE141
43System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 43
CurrentCurrent--Generation Generation ATEsATEs
• 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
44System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 44
Virtual Virtual TAMsTAMs
� 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
45System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 45
Bandwidth MatchingBandwidth Matching
ATE
ATE frequency factor : n = 4
ATE pins : WATE= 4
High frequency pins U = 2
High frequency
ATE lines
Low frequency
ATE lines
BandwidthMatching
10 low frequencylines to the cores
Virtual TAM
TAMTAMATEATE fWfW ×=× ATEWUnW +×−= )1( TAMATETAMTAMTAMATE fUWfnUfUWfU ×−+××=×−+× )()(
EE141
46System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 46
Embedded
core
Parallel-In/
Serial-
out
RegistersATE
SOC
Serial-In/
Parallel-
out
Registers
Low-speed TAM
U
U
U
U
U
U
U
U
WATE -U
Low-speed TAM
High-speed TAM(n = 4)
U
Implementation of Bandwidth MatchingImplementation of Bandwidth Matching
EE141
47System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 47
Selection ofSelection of U U and and nn
�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
48System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 48
SOCsSOCs with Bottleneck Coreswith Bottleneck Cores
222234916q12710
33533416f2126
11935716h953
522842036t512505
54457936p34392
1479440g1023
392648d281
533348u226
T* (clock cycles)W* (bits)SOC
EE141
49System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 49
Relationship of Relationship of U, nU, n and and W*W*
� U and n should be chosen such that total virtual TAM width W does not exceed W*
ATEWWnU −≤−*)1(
*WW ≤
)( UWnUW ATE −+=
EE141
50System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 50
Variation of Variation of UU with with nn
EE141
51System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 51
UU vsvs nn for ITCfor ITC’’02 Benchmarks02 Benchmarks
SOC p34392
W*=36 W*=16
W*=40W*=48
SOC h953
SOC d281 SOC g1023
EE141
52System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 52
MultipleMultiple--Speed TAM ArchitecturesSpeed 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
I/O
pa
ds
I/Op
ad
s
1149.1 TAP controller
Us
er-
de
fin
ed
log
ic
CPUcore
Self-testcontrol
Legacycore
IP hardcore
DSPcore
Memoryarray
Interfacecontrol
EmbeddedDRAM
ATE SOCslow
fast
EE141
53System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 53
Problem FormulationProblem Formulation� Dual-speed optimization problem
Given:
V
W-V
ATE
f.r
r SOC
Embedded
cores
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
54System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 54
TAM width
Te
stin
g t
ime
f.r
TAM width
Te
stin
g t
ime
r
T = 14026.9μsf =2
W-V=23 T = 11398.9μs
V=10
f =1
Core 5 in SOC p93791
fast
Selection of Data Rate for a CoreSelection of Data Rate for a Core
EE141
55System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 55
Matching Core Scan Frequencies to ATE Data Matching Core Scan Frequencies to ATE Data
RatesRates
f = 40MHz f = 80MHz
Core B Core C Core DCore A
f1= 40MHz
Test time
TA
M w
idth
B C
D
w1= 8
w2= 2, f2= 40MHz
T = 456 μμμμs
ABaseline Case 1
EE141
56System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 56
f1= 80MHz
Test time
TA
M w
idth
B
C Dw1= 8
w1= 2, f2= 40MHz T = 275 μμμμs A
BaselineCase 2
Matching Core Scan Frequencies to ATE Data Matching Core Scan Frequencies to ATE Data
RatesRates
f = 40MHz f = 80MHz
Core B Core C Core DCore A
EE141
57System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 57
f1= 80MHz
Test time
TA
M w
idth
B
w1= 5
w1= 5
f2= 40MHz
T = 246 μμμμs
A
C
D
Matching Core Scan Frequencies to ATE Matching Core Scan Frequencies to ATE
Data RatesData Rates
f = 40MHz f = 80MHz
Core B Core C Core DCore A
EE141
58System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 58
Problem StatementProblem StatementGiven
� 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
59System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 59
Solution TechniquesSolution 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
60System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 60
Comparison with BaselineComparison with Baseline
37%
Test
tim
e ( μμ μμ
s)p22810
(5 frequencies: 10 to 50 MHz)
0
50
100
150
200
250
300
(X 100)
16 24 32 40 48 56 64
TAM Width
LB
baseline
proposed
EE141
61System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 61
Comparison with Exact Method and Comparison with Exact Method and
BaselineBaselineT
est
tim
e ( μμ μμ
s)
d695(2 frequencies: 40 MHz and 50 MHz)
0
2
4
6
8
10
12(X 100)
16 24 32 40 48 56 64
TAM Width
ILP
baseline
proposed
EE141
62System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 62
ConclusionsConclusions
� 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
63System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 63
Introduction to NetworkIntroduction to Network--OnOn--Chip TestingChip 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
64System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 64
Conceptual Architecture of a Conceptual Architecture of a NoCNoC SystemSystem� The figure shown below represents a 2-D mesh NoC.
� 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.
Router Router Router
Router Router Router
Core 1 Core 2 Core 3
Core 4 Core 5 Core 6
N bits
EE141
65System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 65
Special Features of Special Features of NoCNoC TestingTesting
� 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
66System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 66
Talk Outline for Testing Embedded Cores Talk Outline for Testing Embedded Cores
in in NoCNoC
� Reuse of OnReuse of OnReuse of OnReuse of On----Chip Network for TestingChip Network for TestingChip Network for TestingChip Network for Testing� Test SchedulingTest SchedulingTest SchedulingTest Scheduling� Test Access Methods and Test InterfaceTest Access Methods and Test InterfaceTest Access Methods and Test InterfaceTest Access Methods and Test Interface� Efficient Reuse of NetworkEfficient Reuse of NetworkEfficient Reuse of NetworkEfficient Reuse of Network
� PowerPowerPowerPower----Aware and ThermalAware and ThermalAware and ThermalAware and Thermal----Aware TestingAware TestingAware TestingAware Testing
EE141
67System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 67
NetworkNetwork--onon--ChipChip
Interconnection schemes:
CPUU
ser
De
fin
ed
Lo
gic
Legacy Core
MemoryArray
IP Hard Core
Self-testControl
InterfaceControl
Embedd-
ed RAM
DSPCore
Core A
Core D
Core C
Core B
Shared bus
Core A
Core D
Core C
Core B
Dedicated connection
Current Design Methodology: System-on-Chip (SoC)
EE141
68System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 68
Need for NetworkNeed for Network--onon--Chip (NOC)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.
Test
� Test of SoC has been well understood� TAM, wrapper
� Test scheduling
� IEEE 1500
� Test needs dedicated hardware
� Hardware for mission-mode communication can
not be reused for testing
EE141
69System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 69
tester
SoC
core core core
corecorecore
NOCNOC--basedbased SystemSystem
EE141
70System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 70
NOCNOC--based Systembased System
Design
� High performance
� High bandwidth
� Low signal delay
� Reasonable overhead
� Suitable for large number
of cores
� Network design is versatile
� Methodology of next
generation VLSI design
Test
� Test of NoC has not received much attention� Core testing
� Router and interconnection testing
� Test wrapper design
� Test scheduling
� No need for dedicated
TAMs
� Network can be reused for
testing
Possible next-generation SoC paradigm: Network-on-Chip (NoC)
EE141
71System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 71
NoCNoC--based Systembased System
d695 from ITC’02 benchmark
� Packet-switching
� Bidirectional channel
� 2-D mesh, XY routing
� Channels, routers used as TAM
� Input/output ports associated with cores
� Ports, channels are assigned a time tag
router router router
router router router
router router router
router router router
Input
Input
Output
Output
1
105 2
3 6 4
9 8 7
EE141
72System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 72
Test Scheduling Using Dedicated Test Scheduling Using Dedicated
Routing Path: NonRouting Path: Non--preemptivepreemptive
� 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 router router
router router router
router router router
router router router
Input
Input
Output
Output
1
105 2
3 6 4
9 8 7
EE141
73System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 73
Test Scheduling: Problem Test Scheduling: Problem
FormulationFormulation
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.
How to assign I/Os and channels to each core for testing such that the overall test time is minimized?
� Equivalent to the resource-constrained multi-processor scheduling problem
� If the number of input/output pairs ≥2, NP-complete
EE141
74System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 74
Test Scheduling: Optimal Test Scheduling: Optimal
Solution Using ILPSolution 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 stillprohibitively high
� Not suitable for large systems
EE141
75System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 75
Test Scheduling: Heuristic Test Scheduling: Heuristic
AlgorithmAlgorithm
� 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
76System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 76
Test Access Method and Test Test Access Method and Test
InterfaceInterface
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
77System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 77
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
2 3 4
1 2 3
1 2 3
Input
1
Input
2
Outpu
t 1
Outpu
t 2Multicast
5 5 6
4 4 6
1 2 3
1 2 3
Input
1
Input
2
Outpu
t 1
Outpu
t 2Unicast
EE141
78System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 78
Test ResponsesCan be handled on-chip
Wrapper
Minimum overhead
Probability of aliasing
Router
MISR
Wrapper
Router
MISR
Wrapper
Router
Comparator
Wrapper
Router
Similar to prior work
Faster, with aliasing
EE141
79System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 79
Test Wrapper
On top of the 1500 compliant wrapper
Can wrap both router and core
Packing/unpacking mechanism reused from mission mode
Router
Core
Unpack
ing
pack
ing
From
adjacent
cores
To
adjacent
cores
1500 compliant
Test mode
EE141
80System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 80
Test Wrapper
Router
Core
Unpack
ingpack
ing
From
adjacent
cores
To
adjacent
cores
Mission mode
EE141
81System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 81
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
Integrated Test Scheduling
EE141
82System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 82
Integrated Test Scheduling
3 4 5
2 3 4
1 2 3
1 2 3
Input 1
Input 2
Output 1
Output 2
6 7 8
4 5 9
1 2 3
1 2 3
Input 1
Input 2
Output 1
Output 2
After these routers are tested, one of the two I/O pairs can be used for core testing
EE141
83System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 83
Fixed channel width, not fully utilized
Efficient Channel Width Utilization
Cores # of packets
Channel width = 16 Channel width = 32
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
84System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 84
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
n =
� Additional cores can be selected to further reduce test
time
Utilization of Idle Channel Width
ww’
EE141
85System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 85
Utilization of Idle Channel Width
Tester
Test data
Slower tester clock
PLL
wrapper
Core B
routerrouter
NoC
Core A
4
4
wrapper
faster on-chip clock
Networkchannel
EE141
86System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 86
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
Channel Width Utilization
Under Power Constraints
A B C A B C
Tester clock
Packets in channel
Test clock on core A
Test clock on core B
Test clock on core C
EE141
87System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 87
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
Power-Aware Test Scheduling
EE141
88System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 88
� 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
Power-Aware Test Scheduling
EE141
89System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 89
ThermalThermal--Aware Test SchedulingAware Test Scheduling
• Existence of hot spots may increase test time because of thermal unbalance
• Layout redesign is impossible
• Layout not optimized for test
• Higher power generation
• Larger thermal variation
• Removal of hot spots can lead to thermal
balance and reduced test time
High power density causes hot spots
30w
10w
9w 8w
5w
10w 8w 5w
40w 55w 15w
5w 13w 18w
EE141
90System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 90
Variable ClockingVariable Clocking in in TestTest SessionSession
• 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
91System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 91
Thermal safe constraints are not violated
Test time reduced
Variable Clocking in TestSession
Clock
Core 1
Core 2
Core 3
Time t1
Clock
Core 1
Core 2
Core 3
Time t2
t1t2 <
EE141
92System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 92
Thermal safe constraints guaranteed
Test time not compromised
Variable Clocking in TestSession
Clock
Core 1
Core 2
Core 3
Time t3
t4t3 =
Clock
Core 1
Core 2
Core 3
Time t4
EE141
93System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 93
Clock
Router
Test packet
f/4
Clock Selection
Unpack reused
Test control can be carried in packetClock varies only when the test of a core finished or started
Unpack Core
f/2 f 2f 4f
PLL
EE141
94System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 94
� 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
Problem Formulation
EE141
95System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 95
Talk Outline for OnTalk Outline for On--Chip Network Chip Network
TestingTesting
� 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
96System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 96
TestingTesting of Interconnect Infrastructuresof 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 speed-up.
� For an interconnect structure with N lines, totally 6N faults are to be tested using 6N two-vector test patterns.
EE141
97System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 97
SelfSelf--Test Structure 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).
� 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.
TDG TEG
sw
itch
sw
itch
sw
itch
EE141
98System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 98
Test Application by Test Application by UnicastUnicast� MAF test patterns can be broadcast to all
interconnects by test packets with only one 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
99System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 99
Test Application by MulticastTest Application by Multicast
� Test packets are broadcast to interconnects of different pairs of routers to achieve maximum parallelism.
� 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
100System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 100
Testing of RoutersTesting of Routers
� Routers are used to implement functions of flow control, routing, switching and buffering of packets.
� 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.
System-on-Chip
channels
NoC
inte
rfa
ces
routers
core 1
core 6
core 5
core 4
core 3
core 2
Pri
ma
ry i
np
uts
of
the
Ch
ip
Pri
ma
ry o
utp
uts
of
the
Ch
ip
R R
R
R
R R
EE141
101System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 101
Testing A Router 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.
� 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.
routing/arbitration
switch
IP
IP
OP
OP
OP
OP
output port
Pri
ma
ry i
np
uts
of
the R
ou
ter
Pri
mary
ou
tpu
ts
of
the R
ou
ter
IOs of the NoC and the Router
Local port
FIFO
FIFO
IP
FIFO
IP FIFOinput port
EE141
102System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 102
Testing All RoutersTesting All Routers� Since all routers are identical, all can be tested in parallel
by test pattern broadcasting.
� Comparator is implemented by XOR gates. It can also support diagnosis.
NoC
SI0 = SO0
router 0
router 2Se0..4
router 1
router 3
EE141
103System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 103
Router Test wrapper Design and TestRouter Test wrapper Design and Test� IEEE-1500 compliant test wrapper is designed to support
test pattern broadcasting and test response evaluation.
NoC
Din_R0[0:19]
control ports
special_in test wrapper
sc1 [0:n]
sc0 [0:m]
sc1 [0:n]
sc0 [0:m]
=
=
router 0
router n
Si[0:2]
Din_Rn[0:19]
Dout_R0[0:19]
Dout_Rn[0:19]
So[0:2]
ci0
ci19
co0
co19
...
...
Fu
nctio
na
l in
puts
Fun
ctio
na
l o
utp
uts
se[0..r]diagnosis
control block
=
=
20
[0]
functional ports router n
functional ports router 0
[19]
[0]
[19]
[0]
[19]
[0]
[19]
modifications required for the test wrapper
EE141
104System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 104
Router Test Wrapper Design and Test (Contd.)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
105System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 105
Network Interface TestingNetwork Interface Testing
� Network interface (NI) is used to receive data bits from its corresponding IP core (router), packetize (de-
packetize) 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
106System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 106
A NI Functional Test ModelA NI Functional Test Model� The NI of AEthereal NoC architecture.
� 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).
Buffers
M-Controller
Buffers
S-Controller
NI Kernel
Aethereal NI
EE141
107System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 107
NI Functional Fault RepresentationNI 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
108System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 108
Number of Functional FaultsNumber 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
109System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 109
Test Scheduling for Functional testingTest 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
110System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 110
Notes for Notes for NoCNoC Functional TestingFunctional 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
111System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 111
Talk Outline for Design and Test Talk Outline for Design and Test
PracticesPractices
� SoC testing for PNX8550 system chip [Goel 2004].
� NoC testing for high-end TV system [Steenhof 2006].
EE141
112System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 112
Case Study: Soc Testing for PNX8550 Case Study: Soc Testing for PNX8550
System ChipSystem Chip� PNX8550 is a chip designed based on Nexperia
digital video platform by Philips [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
113System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 113
Structure of PNX8550Structure of PNX8550� Nexperia home platform
MIPS CPU
D$
I$PRxxxx
IP MODULE
IP MODULE
IP MODULE
TriMedia CPU
D$
I$TMxxxx
IP MODULE
IP MODULE
IP MODULE
MMI
SDRAM
SOC Bridge
EE141
114System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 114
PNX8550 Structure and Test MethodsPNX8550 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% stuck-at fault coverage, small embedded memories – scan test, large memories – BIST.
EE141
115System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 115
PNX8550 Test StrategiesPNX8550 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.
� Philips 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
116System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 116
TRTR--ARCHITECT InputsARCHITECT 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
117System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 117
TAM Wires Distribution and Test Architecture 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
118System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 118
Test Architecture Design for Each Test Architecture Design for Each ChipletChiplet
� 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, TR-
ARCHITECT 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
119System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 119
TRTR--ARCTITECT Major ProceduresARCTITECT 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
120System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 120
Example for OptimizeExample for Optimize--bottombottom--upup
� 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
121System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 121
TRTR--ARCHITECT Major Procedures and ResultsARCHITECT 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
122System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 122
Case Study: Case Study: NoCNoC Testing for HighTesting for High--End TV End TV
Companion Chip by PhilipsCompanion Chip by Philips� 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].
EE141
123System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 123
Main TV Chip and Companion ChipMain 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 high-speed 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
124System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 124
System TasksSystem 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).
EE141
125System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 125
Companion Chip Companion Chip -- NoCNoC ImplementationImplementation� 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.
EE141
126System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 126
Companion Chip Companion Chip -- NoCNoC Implementation (Contd.)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).
EE141
127System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 127
Test Methods for PhilipsTest Methods for Philips’’ AEthrealAEthreal NoCNoC
� Test methods for Philips’ 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
128System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 128
Test Methods for PhilipsTest Methods for Philips’’ AEthrealAEthreal NoCNoC
(Contd.)(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.
EE141
129System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 129
Concluding RemarksConcluding 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
130System-on-Chip Test Architectures Ch. 4 – SOC and NOC Testing - P. 130
Concluding Remarks (Contd.)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 SoCand NoC designs.