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

Präsentation zum Thema: "Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus 1 Hierarchical Test Technology for Systems on a."—  Präsentation transkript:

1

2 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus 1 Hierarchical Test Technology for Systems on a Chip (SoCs) Heinrich Theodor Vierhaus Brandenburg University of Technology Cottbus Computer Engineering Group

3 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 2 Outline 1. 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

4 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 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.

5 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 4 Multi-Processor System on a Chip

6 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 5 Structure of an MP-SoC Multiple processor devices Multiple local and global interconnects Embedded memories Locally synchronous, globally asynchronous Limited external test access Building blocks not designed for test

7 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 6 2. Test Technology for SoCs Not everything is new, but almost everything is bigger....

8 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 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

9 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 8 Status of Test Technology Wrappers around functional blocks for improved (functional) test access (IEEE P 1500) Scan-based logic test using multiple scan paths and test pattern compaction / de-compaction (e.g. EDT, Mentor Graphics) Logic BIST with deterministic patterns, BIST for 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

10 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 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 according to learning curves Deterministic HW BIST costs overhead But HW BIST can be part of SW-based self test schemes for startup-test in the field!

11 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 10 3. A Hierarchical Self Test Technology for SoCs Processor-based systems open a new dimension for self test. But you need a reliable core to start with...

12 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 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!

13 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 12 Bottom-Up Test Scheme for Startup-Tests Boot Device triggers external logic test / BIST and memory BIST Step 3 Functional tests e. g. for local interconnects Step 4 Step 2 Boot Device tests vital global interconnects Step 1 Boot Device Memory BIST and Self Test

14 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 13 MP-SoC with Test Processor Test- Processor Test Pr.- Memory Local Memory DSP Local Memory DSP RISC Local Memory FU 1FU 2FU 3 Scan-Controller Scan Contr. B I S T B I S T B I S T BIST control Control & data transfer for embedded scan test

15 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 14 Test- processor Testpr.- Memory Lokales Memory DSP Lokales Memory DSP RISC Lokales Memory FU 1FU 2FU 3 Scan-Controller B I S T Scan Contr. B I S T B I S T B I S T BIST Tester SoC- Production Test

16 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 15 4. The Test Processor Why cant we take on of the processors on an SoC and have it doing all test functions in software?

17 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 16 Boundary Conditions An internal test processor replaces the external tester 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, the device must be small and low power.

18 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 17 The Test Processor 16 Bit RISC Architecture (no pipelines) DLX-compatible instruction set Internal registers can be configured to work as LFSR and / or MISR with special instructions Fast comparison of external port registers for watchdog operation Designed for optimized functional testability of logic, registers, ports and internal busses Control logic with on-line self test features Complexity: 5000 gates (for FPGA implementation) Functional test procedure: 2948 Bytes

19 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 18 Test Processor Data Path

20 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 19 Test Processor Control Logic Sequencer C o n t r o l W o r d Instruction Decoder Control Logic Flags Stop Reset IR Clock Q T Y BUS Control Lines

21 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 20 Test Processor Special Self-Test Features Testability of busses and register files for static and dynamic faults On-line self test strategy for control logic Special hardware support to validate the number of clock cycles required for a test routine Minimum size test routine exhibity reasonable stuck-at fault coverage: 93.3% data path, 86.2 % control logic, 64.9 % I / O ports

22 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 21 5. Bus-Tests Local bus structures (e. g. within a processor device) on SoCs can only be tested functionally. Global bus structures are frequently operated asynchronously, but require a deterministic test under worst case conditions.

23 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 22 Dynamic Worst Case Test Bus- Driver 0 0 0 0 1 0 1 1 1 1 1 Recei- ver testSequence1 pattern 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 testSequence n 0

24 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 23 Testing Bus Structures Test- Processor I / O-Buffers Bus Master Bus Master Bus Master Bus Master Bus Master Bus Master Bus Reflector bus stuck-atfault / bridgefault shielding bus line resistance

25 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 24 Test Scheme for Global Bus 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

26 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 25 Bus-Test-Reflector from bus inv ctrl to Bus Bus Master Reflector

27 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 26 Bus Test Timing

28 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 27 Control Scheme for Bus Tests Test Processor (replacing bus arbiter device) Bus Master Bus Master Bus Master clock reflector select invert control data lines Busreflector

29 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 28 Test Processor with Periphery for Bus-Test General Purpose Register LFSR / MISR ALU Control Par.I / O P1 Par.I / O S1 Ser. I / O P2 Par. I / O A Fast compare 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

30 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 29 Bus-Test with Parity Check Test Processor Core Parity Encoder Bus Reflector Parity Check Error bit Parity bit Bus I /O MISR I /O I /O Registers

31 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 30 Parity-Bit with functional Test Test Processor Core Parity encoder Bus Reflector Parity Check Error bit Parity bit Parity latch I / O Tristate driver 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.

32 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 31 Can we Test Faults on Memory Interfaces of External Processors? Test-Processor P0 P1 Bus-Interface CPU Local Memory Addresses Daten BK Bus-Interface P4 I / O 2 parallel 16-Bit I / O Register P2 P3 BKL Global test bus control Yes, but we need a separate test bus. And we Cannot test the I / O ports of the external CPU.

33 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 32 Testing Logic Units on an SoC Pure functional tests for logic units hardly reaches 99 % static fault coverage. Embedded scan test is feasible with close-to 100 % coverage of static faults (only) Test patterns for scan test can be compacted by a factor of 30 to 50. Compaction rates for functional tests may Reach a factor of 2 to 5 only.

34 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 33 6. Supporting On-line-Test Can we use structures that are necessary for off-line self test also for on-line test??

35 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 34 On-line-Test for Self-Testing Processors Counter Error bits Counter Error bits Test bus Enable Control bits Test Processor ls Watchdog reset Data path Control - path checker

36 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 35 Intelligent Watchdog-Function Supervising Code Addressing

37 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 36 Maximum-Minimum Observation Main ProcessorMemory Address Data Address Select Watchdog Processor Variable ident Variable value Critical Variables Min, Max, maxrise, maxfall Interrupt Test bus

38 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 37 Error Correction Main ProcessorMemory Address Data Address Select Watchdog Processor Variable ident Variable value Critical Variables Min, Max, maxrise, maxfall Interrupt Test bus Probable data value Corected value real address

39 Lehrstuhl Technische Informatik - Computer Engineering Brandenburgische Technische Universität Cottbus H. T. Vierhaus Mai 2004 38 8. Lots of Unsolved Problems Software Validation / Verification Hardware test for large complexities and dynamic faults in combination Fault tolerant system design for multiple faults Fault diagnosis and self repair