Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
6 views86 pages

Clase 8

The document discusses the design and testing of state-of-the-art Systems on Chip (SoCs), focusing on core-based systems and the challenges associated with testing them. It highlights the importance of design reuse, standardization initiatives like IEEE P1500, and the implementation of Network-on-Chip (NoC) for efficient communication and testing access. Additionally, it addresses the need for increased test parallelism and the potential of using microprocessors as test sources to minimize test time and area overhead.

Uploaded by

benderbundy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views86 pages

Clase 8

The document discusses the design and testing of state-of-the-art Systems on Chip (SoCs), focusing on core-based systems and the challenges associated with testing them. It highlights the importance of design reuse, standardization initiatives like IEEE P1500, and the implementation of Network-on-Chip (NoC) for efficient communication and testing access. Additionally, it addresses the need for increased test parallelism and the potential of using microprocessors as test sources to minimize test time and area overhead.

Uploaded by

benderbundy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 86

Testing State-of-the-art

Systems on Chip

Marcelo Lubaszewski

Universidade Federal do Rio Grande do Sul


Departamento de Engenharia Elétrica
Porto Alegre - RS - Brasil
e-mail: [email protected]
Electronic Systems Design

• High level specification


• Mixed-technologies
– HW and SW
– optical, analogue, digital, micro-mechanical

• Design reuse and automation


• Design for test
Design Reuse
hard
Soft
ENTITY MUX _2
(
in_1 : IN bit_vector(m downto 0);
in_2 : IN bit_vector(m downto 0);
selector : IN bit;
out : out bit_vector(m downto 0)
);
...

Firm
Core-Based Systems

System
A/D
Analogue sensor Converters
(hard) (hard)

DMA μprocessor
(firm) (soft)
Core-Based Systems

System
A/D CONTROL
Analogue sensor Converters
(hard) (hard) Arithmetic
unit
DMA μprocessor ROM
(firm) (soft)
Core-Based Systems

System
A/D CONTROL
Analogue sensor Converters
(hard) (hard) Arithmetic
unit
DMA μprocessor ROM
(firm) (soft)

Core-based system-on-chip
(SoC)
Core-based Systems

• Less design effort


Core-based Systems

• Less design effort

• Several description styles


• IP protection
• Harder to validate and test
Outline

• Test requirements of core-based systems


• Standardization initiatives
• Test planning of state-of-the-art SoCs
– NoC-based TAM
– Multiprocessors on-chip
– Mixed-signal cores testing
Test Steps - System-on-Board
RTL description Logic Validation

Synthesis

Hardware description Synthesis Verification

Manufacturing

Production Test

Interconnections
verification
Test Steps - System-on-Chip
Core description Core description Core description
#1 #2 #n

Logic Verification Logic Verification Logic Verification

SOC description
core #n
core #1 Logic Verification
core #2

Synthesis

Production Test

System Test
SoC Test Challenges

Core #1 Core #2

Core #3 Core #n

- core test
- test information
SoC Test Challenges

SOC
User Defined
Logic

Core #1 Core #2

Core #3 Core #n

- core designer
Test Schemes

SOC
User Defined
Logic

Core #1 Core #2

Core #3 Core #n

- BIST
- Scan chains
- ad-hoc
SoC Test Challenges

- interconnection test
- test access
TestCore
vectors
#1 Core #2

Core #3 Test Core #n


responses
SoC Test Challenges
- system designer
SOC
User Defined
Logic

TestCore
vectors
#1 Core #2

Core #3 Test Core #n


responses
Test Schemes

- multiplexing modes
SOC - test busses insertion
User Defined
- use of transparency
Logic

Core #1 Core #2

Core #3 Core #n
SoC Test Challenges
- test integration
- UDL test
SOC - test scheduling
User Defined
Logic - test controller

Core #1 Core #2
- system restrictions
• test time
• area overhead
• power
Core #3 Core #n • time-to-market
SoC Test Challenges
- system designer
SOC
User Defined
Logic

TestCore
vectors
#1 Core #2

Core #3 Test Core #n


responses
Test Schemes

SOC
User Defined - test controller
Logic
- boundary scan compatibility
Core #1 - microprocessors reuse
Core #2

Core #3 Core #n
Outline

• Test requirements of core-based systems


• Standardization initiatives
• Test planning of state-of-the-art SoCs
– NoC-based TAM
– Multiprocessors on-chip
– Mixed-signal cores testing
Standardization Initiatives
IEEE P1500
– interface between core providers and users

SRAM PCI
ROM

CUT
CPU DRAM

MPEG
SOC
Conceptual Architecture

SRAM PCI
ROM

test data test access CUT test access test data


source mechanism mechanism sink
CPU DRAM

MPEG
SOC
Conceptual Architecture

SRAM PCI
ROM

test data test access CUT test access test data


source mechanism mechanism sink
CPU DRAM

MPEG
SOC

external, built-in or both


Conceptual Architecture

SRAM PCI
ROM

test data test access CUT test access test data


source mechanism mechanism sink
CPU DRAM

MPEG
SOC

test busses, scan chains, bus sharing, control functions


Conceptual Architecture

SRAM PCI
ROM

test data test access CUT test access test data


source mechanism mechanism sink
CPU DRAM

MPEG
SOC

normal, internal test, external test, transparency


Wrapper P1500 Básico
WRAPPER

WBR
WBR

n
m
CORE

WBY
WSO
WSI Wrapper Instruction Register

n
wc WPI
Parallel Bypass
WRAPPER

WBR

WBR
n
m
CORE

WBY
WSO
WSI Wrapper Instruction Register

wc n
Serial Bypass
WRAPPER

WBR
WBR

l
m
CORE

WBY
WSO
WSI Wrapper Instruction Register

wc n
Wrapper Instruction Register
WRAPPER

WBR
WBR

n
m
CORE

WBY
WSO
WSI Wrapper Instruction Register

n
wc
Outline

• Test requirements of core-based systems


• Standardization initiatives
• Test planning of state-of-the-art SoCs
– NoC-based TAM
– Multiprocessors on-chip
– Mixed-signal cores testing
State-of-the-art in SoC design
SoC design
• communication among
cores
• Network-on-chip
State-of-the-art in SoC design
Bus NoC
• long wires • shorter wires
• synchronous system • modular architecture
– clock skew • GALS system:
– power consumption – globally asynchronous and locally
• much simpler synchronous
• no parallelism – lower power consumption in
channels
• limited bandwidth – support for multiple clocks
– uses handshake for
communication
• higher silicion area
• parallelism/pipeline
State-of-the-art in SoC testing
SoC design SoC testing
• communication among • access to cores
cores • test bus, reuse
• Network-on-chip • extra hardware
Putting design and test to pace
SoC design SoC testing
• communication among • access to cores
cores • test bus, reuse
• Network-on-chip • extra hardware

NoC-based SoC

• available access to each embedded core


• efficient communication mechanism
• reuse the NoC as Test Access Mechanism (TAM)
Outline

• Test requirements of core-based systems


• Standardization initiatives
• Test planning of state-of-the-art SoCs
– NoC-based TAM
– Multiprocessors on-chip
– Mixed-signal cores testing
NoC Basics

Core 1 Core 2 Core 3

Core 4 Core 5 Core 6


NoC Basics

Core 1 Core 2 Core 3

Router Router Router

Core 4 Core 5 Core 6

Router Router Router


NoC Basics

Router Router Router

Router Router Router


N bits
NoC Basics

• Read header
– store message
– compute destination

core
NoC Basics
payload

payload
payload

header
tail

Router Router Router

Router Router Router


NoC Basics

payload
payload
payload

header
tail

Router Router Router

Router Router Router


NoC Basics

payload
payload
payload

header
tail

Router Router Router

Router Router Router


NoC Basics

payload
payload

payload

header
tail

Router Router Router

Router Router Router


NoC Basics

payload
payload
payload

header
tail

Router Router Router

Router Router Router


NoC Basics

payload

payload
payload

header
tail
Router Router Router

Router Router Router


NoC Basics

payload

payload
payload

header
tail
Router Router Router

Router Router Router


NoC Basics

Core 1 Core 2 Core 3

Router Router Router

Core 4 Core 5 Core 6

Router Router Router


NoC Basics

Core 1 Core 2 Core 3


r er
r p e p p
p e a p r a
a p w r w
w r
Router Router Router

Core 4 Core 5 Core 6


er r
er p p p e
p a p
ap w r r a
wr w
Router Router Router
Reuse Model

SoC
core core core

core core core


Reuse Model

tester

SoC
core core core

core core core


Reuse Model

tester

SoC
core core core

core core core


Reuse Model

tester

SoC
core core core

core core core


Reuse Model
Wrapper:
- test mode
- basic P1500 modes

SoC
core core core

core core core


NoC-based Test

01

1011
0100
0001

10 01 1 01
CUT
NoC-based Test
• Test vector = test packet
01

1011
packet header 0100
test header 0001
payload

10 01 1 01
payload CUT
payload
payload
tail
NoC-based Test
• Test vector = test packet
01

1011
packet header 0100
test header 0001
payload

10 01 1 01
payload CUT
payload
payload
tail
NoC-based Test
• Test vector = test packet

packet header 1011


test header 0100
payload 0001

10 01 1 01
payload CUT
payload
payload
tail
NoC-based Test
• Test vector = test packet
01

1011
packet header 0100
test header 0001
payload

10 01 1 01
payload CUT
payload
payload
tail
NoC-based Test
• Test vector = test packet

1011
packet header 0100
test header 0001
payload

10 01 1 01
payload CUT
payload
payload
tail
NoC-based Test
• Test vector = test packet

1011
packet header 0100
test header 0001
payload

01 1 01
payload CUT
payload
payload

10
tail
NoC-based Test
• Test vector = test packet

1011
packet header 0100
test header 0001
payload

1 01
payload CUT
payload

10 01
payload
tail
NoC-based Test
• Test vector = test packet

1011
packet header 0100
test header 0001
payload

10 01 1 01
payload CUT
payload
payload
tail
NoC-based Test
• Test vector = test packet

packet header
test header
payload
payload CUT
payload
payload
tail
Parallelism Within the NoC
input

input
CUT 1

CUT 2
output

output
Parallelism Within the NoC
input

input
CUT 1

CUT 2
output

output
Parallelism Within the NoC
input

input
CUT 1

CUT 2
output

CUT 3

output
Parallelism Within the NoC
BOTTLENECKS!

input
CUT 1

CUT 2

CUT 3

output
Packets Scheduling

input
CUT 1

CUT 2

CUT 3

output
Packets Scheduling

input
CUT 1

CUT 2

CUT 3

output
Packets Scheduling

input
CUT 1

CUT 2

CUT 3

output
Packets Scheduling

input
CUT 1

CUT 2

CUT 3

output
Packets Scheduling

input
CUT 1

CUT 2

CUT 3

output
Outline

• Test requirements of core-based systems


• Standardization initiatives
• Test planning of state-of-the-art SoCs
– NoC-based TAM
– Multiprocessors on-chip
– Mixed-signal cores testing
Microprocessor Reuse
Problem statement:
• NoC-based test:
– pros: network reuse as TAM, highly parallel
testing of cores
– cons:
• limited by the number of interfaces with ATE
– low use of intrinsic network parallelism
• add specific pins for testing may be too costly
– packaging

How further explore existing parallelism and


minimize test time?
Microprocessor Reuse
General approach:
• Increase test parallelism (re)using embedded
cores as test sources and sinks
– reuse functional cores
• μcontrollers, μprocessors, DSP
– pros: no area overhead
– cons: higher test time due to general purpose of core
– add test specific hardware
• ProBIST, MET, LSFR, MISR
– pros: lower test time due to specificity of core
– cons: area overhead, performance degradation
Microprocessor Reuse
Why the μP ?
• reduce area overhead
• make test development more flexible (software)
• reduce test time wrt to external testing
• new tendences point to “Sea of Processors”
architectures
– ↑ programmable units
• ↑ ASIP/RISC/VLIW/DSP
– ↑ FPGA
– ↓ specific logic
• ↓ ASIC (MPEG,PCI,USB,...)
– NoC
Microprocessor Reuse
Before....
input

input
CUT 1

CUT 2
output
Only SoC
CUT 3
interfaces
are used
output
Microprocessor Reuse
After....
input

μP

input
CUT 1

CUT 2 μP
output
Also uses
CUT 3
functional
units
output
Outline

• Test requirements of core-based systems


• Standardization initiatives
• Current approaches
• Test planning of state-of-the-art SoCs
– NoC-based TAM
– Multiprocessors on-chip
– Mixed-signal cores testing
Adding Analog
State-of-the-art SoCs:
• x86 compatible processor
• Memory
• Bluetooth networking
• Sound/Voice analog interfaces
• VGA CMOS camera interface
• LCD display interface
• USB
Adding Analog
Problem statement:
• In general, analog test is costly:
– mixed-signal testers are expensive
– long test times are needed due to extensive types
of measurements and/or number of samples

1997 future [Roberts,’97]


Adding Analog
Problem statement (cont’d):
• Analog test in SoC environment suffers from:

– access problems
• bus and NoCs are digital only
• specific analog TAMs are needed
• mixed-signal wrapper may interface with digital TAMs
• mixed-signal wrapper is too costly (ADC+DAC)

– long test times due to low frequencies


• most applications are in the audio range
Adding Analog
General approach:
• Analog and mixed-signal BIST:
– reusing digital cores
• μcontrollers, μprocessors, DSP, memory
– higher test time due to serial testing
– may require lots of memory

– use stand-alone BISTed cores


• Oscillation-based, for example
– lower test time due to parallell testing
– area overhead of evaluation circuitry may be important
Adding Analog
Why processor reuse ?

• BIST with reduced area overhead

• make BIST development more flexible (software for


computing FFT, for example)

• may reduce test time wrt to external testing

• new tendences point to multiprocessor architectures


Adding Analog
Expectations:
• analog dominates test time due to big number of samples
and low frequencies

• Reuse-based BIST potentially reduces test time due to


possible parallel cores test

• power consumption is very important for analog, and may


limit parallel testing

• when available, multiple processors can be explored to


reduce test time

You might also like