Hierarchical Test Technology for Systems on a Chip (SoCs)

1. Hierarchical Test Technology for Systems on a Chip (SoCs) Heinrich Theodor Vierhaus Brandenburg University of Technology Cottbus Computer Engineering Group

2. Outline 1. Multi-Processor „System on a Chip“ (SoC) 2. Test Requirements for SoCs 3. A Hierarchical Self Test Scheme 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 Multiple processor devices Multiple local and global interconnects Embedded memories Locally synchronous, globally asynchronous Limited external test access Building blocks not designed for test

6. 2. Test Technology for SoCs Not everything is new, but almost everything is 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 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

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“!

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 ...

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. Step 4 Functional tests e. g. for local interconnects Step 3 Boot Device triggers external logic test / BIST and memory BIST Step 2 Boot Device tests vital global interconnects Step 1 „Boot Device“ Memory BIST and Self Test Bottom-Up Test Scheme for Startup-Tests

13. MP-SoC with Test Processor Control & data transfer for embedded scan test Scan -Controller DSP DSP B B BIST control I I Local Local S S Memory Memory T T B . FU 1 FU 2 FU 3 I Test Pr .- S Scan Contr Memory BIST T Local RISC Memory Test- Processor

14. SoC- Production Test Scan -Controller DSP DSP B B I I Lokales Lokales Tester S S Memory Memory T T B . FU 1 FU 2 FU 3 I Testpr .- S Scan Contr Memory BIST T Lokales B RISC Memory I Test- S processor T

15. 4. The Test Processor Why can‘t we take on of the processors on an SoC and have it doing all test functions in software?

16. Boundary Conditions An internal test processor replaces the external tester for off-line self tests „in the field“. 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“. Time-critical functions have to be covered by „local“ self test, e. g. for memory blocks.

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

18. Test Processor Data Path

19. Test Processor Control Logic BUS Control C o n Control Lines IR Q Instruction Decoder t r Y Flags o Control Logic l Stop T W Clock Sequencer o r Reset d

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

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.

22. Dynamic „Worst Case“ Test pattern propagation test Sequence n test Sequence 1 0 0 1 0 1 0 0 0 1 1 0 1 0 0 1 1 0 1 Bus - Recei - 0 0 1 1 0 1 Driver ver 0 0 1 1 0 1 1 1 0 1 0 1 reflected pattern

23. Testing Bus Structures Test - Processor I / O - Buffers Bus Bus Master Master „ shielding “ bus line resistance Bus Bus Master Master Bus Reflector Bus Bus Master Master bus stuck - at fault / bridge fault

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

25. Bus-Test-Reflector Reflector from bus Bus Master to Bus inv ctrl

26. Bus Test Timing

27. Control Scheme for Bus Tests Bus Master Bus reflector data lines Bus Bus Master Master clock Test reflector select Processor (replacing bus arbiter device) invert control

28. Test Processor with Periphery for Bus-Test Par.I / O Par.I / O ALU General Purpose Register P1 Clock cycle t Ser. I / O Fast compare S1 Bus Control P2 LFSR / MISR LFSR / MISR Clock cycle (t+1) clock for. Reflector Par. I / O Par I / O Par. I / O A B Error- Bit Select Reflector Refl. Invert Control, set to „1“

29. Bus-Test with Parity Check I /O Registers Test Processor Core Parity Encoder Bus I /O Parity bit Bus Reflector Parity Check MISR Error bit I /O

30. Parity-Bit with functional Test I / O Tristate driver Test Processor Core Con- trol Parity encoder Parity bit Parity latch Bus Reflector Parity Check (Bus-Reflector is inactive) I / O Error bit 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? Bus - Interface 2 parallel 16 - Bit CPU I / O Register P0 Bus - Interface Daten P1 Addresses BK Test - Processor Global test BK P2 bus BKL P3 P4 Local control I / O Memory Yes, but we need a separate test bus. And we Cannot test the I / O ports of the external CPU.

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.

33. 6. Supporting On-line-Test Can we use structures that are necessary for off-line self test also for on-line test??

34. On-line-Test for Self-Testing Processors Control - Data path path checker checker Error bits Error bits Counter Counter reset reset Enable Enable Test bus Test Processor ls Control bits „ Watchdog “

35. Intelligent Watchdog-FunctionSupervising Code Addressing

36. Maximum-Minimum Observation Address Main Processor Memory Data Interrupt Address Select Critical Variables Variable ident Test bus Variable value Min, Max, Dmaxrise, Dmaxfall Watchdog Processor

37. Error Correction Address Main Processor Memory Data Interrupt Corected value real address Address Select Critical Variables Variable ident Test bus Variable value Min, Max, Dmaxrise, Dmaxfall Watchdog Processor Probable data value

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