Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus 1 Hierarchical Test Technology for Systems on a

1

Lehrstuhl Technische Informatik - Computer Engineering

Brandenburgische Technische Universität Cottbus

Hierarchical Test Technology for Systems

on a Chip (SoCs)

Heinrich Theodor VierhausBrandenburg University of

Technology CottbusComputer Engineering Group

2



H. T. Vierhaus Mai 2004

Outline1. Multi-Processor „System on a Chip“ (SoC)

3. A Hierarchical Self Test Scheme

2. Test Requirements for SoCs

4. The Test Processor

5. Functional Self Test

6. Testing Local and Global Bus Structures

7. Supporting On-line-Test

8. Lots of Unsolved Problems

3




1. Multi-Processor „System on a Chip“ (MP-SoC)

State-of-the-art SoCs are heterogeneous multi-processor systems with asynchronous communication.

Traditional IC test technology works on synchronous systems only.

4




Multi-Processor „System on a Chip“

5




Structure of an MP-SoC

LocalMemory

DSP

LocalMemory

DSP

RISCLocalMemory

FU 1 FU 2 FU 3globalbus

localbus

Buscoupler

globalbus

Multiple processordevices

Multiple local andglobal interconnects

Embedded memories

Locally synchronous,globally asynchronous

Limited externaltest accessBuilding blocks notdesigned for test

6




2. Test Technology for SoCs

Not everything is new, but almost everythingis bigger....

7




Test Requirements for SoCs

• SoCs are increasingly used in safety-critical application

• SoCs need to be designed for self test „in the field“

• SoC test technology should be useful for production test and self test „in the field“

8




Status of Test Technology„Wrappers“ around functional blocks for improved (functional) test access (IEEE P 1500)

Scan-based logic test using multiple scan pathsand test pattern compaction / de-compaction(e.g. EDT, Mentor Graphics)

Logic BIST with deterministic patterns, BISTfor embedded memories (e. g. U. Stuttgart and Philips)

Remaining Problems:Testing busses and other interconnects „at speed“Off-line test „in the field“Online-test, error correction

9




Can HW-based BIST solve all problems?

BIST functions often need an external device(e. g. an IC tester) for overall control

HW-based BIST is difficult to modify accordingto „learning curves“

Deterministic HW BIST costs overhead

But HW BIST can be part of SW-based self testschemes for startup-test „in the field“!

10




3. A Hierarchical Self Test Technology for SoCs

Processor-based systems open a new dimensionfor self test. But you need a reliable core to start with ...

11




Can SoCs Test Themselves ?

Partly Yes!!

- Embedded memories are equipped for structure-oriented self test

- Processors or other blocks may have logic BIST facilities

But such functions are not accessible for a functional self test after production!

12




Bottom-Up Test Scheme for Startup-Tests

Boot Device triggersexternal logic test /

BIST and memory BIST

Step 3

Functional tests e. g. for local

interconnects

Step 4

Step 2 Boot Device testsvital global

interconnects

Step 1 „Boot Device“Memory BIST and Self Test

13




MP-SoC with Test Processor

Test-Processor

Test Pr.-Memory

LocalMemory

DSP

LocalMemory

DSP

RISCLocalMemory

FU 1 FU 2 FU 3

Scan-Controller

Sca

n C

ontr.

BIST

BIST

BIST

BIST

BISTcontrol

Control& data transferfor embeddedscan test

14




Test-processor

Testpr .-Memory

LokalesMemory

DSP

LokalesMemory

DSP

RISCLokales

Memory

FU 1 FU 2 FU 3

Scan -Controller

BIST

Scan

Con

tr. B

IST

BIST

BIST

BIST

Tester

SoC- Production Test

15




4. The Test Processor

Why can‘t we take on of the processors onan SoC and have it doing all test functionsin software?

16




Boundary Conditions

An internal test processor replaces the externaltester for off-line self tests „in the field“.

Time-critical functions have to be covered by„local“ self test, e. g. for memory blocks.

A processor that governs test functions has to be deterministic and self-testing. These features are not available from standard processors.

If we afford an additional test processor, thedevice must be small and „low power“.

17




The Test Processor16 Bit RISC Architecture (no pipelines)DLX-compatible instruction setInternal registers can be configured to work asLFSR and / or MISR with special instructionsFast comparison of external port registers forwatchdog operationDesigned for optimized functional testabilityof logic, registers, ports and internal bussesControl logic with on-line self test features

Complexity: 5000 gates (for FPGA implementation)

Functional test procedure: 2948 Bytes

18




Test Processor Data Path

19




Test Processor Control Logic

Sequencer

Control

Wo r

d

InstructionDecoder

ControlLogic

Flags

Stop

Reset

IR

Clock

Q

T

Y

BUSControl

ControlLines

20




Test Processor Special Self-Test Features

Testability of busses and register files forstatic and dynamic faultsOn-line self test strategy for control logic

Special hardware support to validate thenumber of clock cycles required for a testroutine

Minimum size test routine exhibity reasonablestuck-at fault coverage:

93.3% data path, 86.2 % control logic, 64.9 % I / O ports

21




5. Bus-Tests

Local bus structures (e. g. within a processordevice) on SoCs can only be tested functionally.

Global bus structures are frequently operatedasynchronously, but require a deterministic testunder „worst case“ conditions.

22




Dynamic „Worst Case“ Test

Bus-Driver

0

0

0

0

1

0

1

1

1

1

1

Recei-ver

test Sequence 1pattern propagation

reflected pattern

1

0

0

0

0

0

0

1

1

1

1

1

1

1

1

1

1

0

0

0

0

0

0

1

test Sequence n

0

23




Testing Bus Structures

Test-Processor

I / O-Buffers

BusMaster

BusMaster

BusMaster

BusMaster

BusMaster

BusMaster

BusReflector

bus stuck-at fault /bridge fault

„shielding“bus line resistance

24




Test Scheme for GlobalBus Tests

• Test processor with special bus write / read instruction for 2 parallel ports

• Bus masters replaced by „bus reflector“ devices that reflect incoming signals after one clock with inversion

• Bus reflectors can be controlled using bus request / bus access grant lines

25




Bus-Test-Reflector

from bus

invctrl

toBus

+

clock

CL

TG

S

S

TGS

S

invert control

normalout

latchedout

&refl. activate

in

D

Bus Master

Reflector

26




Bus Test Timing

tTest pattern Transfer tobus

Non-invertedbus response

Inverted busresponse Next pattern

TransferTo bus

Bus clock

27




Control Scheme for Bus Tests

TestProcessor(replacing busarbiter device)

BusMaster

BusMaster

BusMaster

clock

reflector select

invert control

data lines

Bus reflector

28




Test Processor with Periphery for Bus-Test

GeneralPurposeRegister

LFSR / MISR

LFSR / MISR

ALU

Control

Par.I / O

P1

Par.I / O

S1

Ser. I / O

P2

Par. I / OA

Fastcompare

B

Par. I / O Par I / O

Bus

Select Reflector Refl. Invert Control,

set to „1“

Error-Bit

Clock cycle t

Clock cycle (t+1)clock for.Reflector

29




Bus-Test with Parity Check

TestProcessor

Core

ParityEncoder

Bus Reflector

ParityCheck

Error bit

Parity bitBus I /O

MISR I /O

I /O Registers

30




Parity-Bit with functional Test

TestProcessor

Core

Parityencoder

Bus Reflector

ParityCheck

Error bit

Parity bitParitylatch

I / O

Tristatedriver

I / O

Con-trol

(Bus-Reflector is inactive)

A „false“ word with parity can be sent around the encoder. The„good“ word is encoded in the normal output.

31




Can we Test Faults on Memory Interfaces of External Processors?

Test-Processor

P0

P1

Bus-Interface

CPU

LocalMemory

AddressesDaten

BK

BK

Bus-Interface

P4

I / O

2 parallel 16-BitI / O Register

P2

P3BKL

Global testbus

control

Yes, but we need a separate test bus. And weCannot test the I / O ports of the external CPU.

32




Testing Logic Units on an SoC

Pure functional tests for logic units hardlyreaches 99 % static fault coverage.

„Embedded“ scan test is feasible with close-to100 % coverage of static faults (only)

Test patterns for scan test can be compactedby a factor of 30 to 50.

Compaction rates for functional tests may Reach a factor of 2 to 5 only.

33




6. Supporting On-line-Test

Can we use structures that are necessary foroff-line self test also for on-line test??

34




On-line-Test for Self-Testing Processors

Counter

Error bits

Counter

Error bits

Testbus

Enable Enable

Control bits Test Processor ls„Watchdog“

resetreset

Data pathControl-path

checker checker

35




Intelligent Watchdog-FunctionSupervising Code Addressing

Processor

Adressbus

Adress split

Code Daten

Databus

ROM RAM

MISR

Code

Test Processor

Counter

Ref Cl No.

Comp

36




Maximum-Minimum Observation

Main Processor Memory

Address

Data

AddressSelect

WatchdogProcessor

Variable ident

Variable value

Critical Variables

Min, Max,maxrise,maxfall

Interrupt

Testbus

37




Error Correction

Main Processor Memory

Address

Data

AddressSelect

WatchdogProcessor

Variable ident

Variable value

Critical Variables

Min, Max,maxrise,maxfall

Interrupt

Testbus

Probable data value

Corected valuereal address

38




8. Lots of Unsolved Problems

Software Validation / Verification

Hardware test for large complexities and dynamicfaults in combination

Fault tolerant system design for multiple faults

Fault diagnosis and self repair

Documents

Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus 1 Hierarchical Test Technology for Systems on a