SLIDE 1
1
2
A BIST Implementation Framework for Supporting Field Testability - - PowerPoint PPT Presentation
A BIST Implementation Framework for Supporting Field Testability - - PowerPoint PPT Presentation
DSN 2007 Workshop June 28, 2007 A BIST Implementation Framework for Supporting Field Testability and Configurability in an Automotive SOC Amit Dutta, Srinivasulu Alampally, Arun Kumar and Rubin Parekhji Texas Instruments, Bangalore
SLIDE 2
SLIDE 3
3
Presentation Outline
Requirements of manufacturing and field test. Overview of techniques. Applicable scope. System level requirements for self-test. Logic self-test architecture and implementation. Memory self-test and self-repair. Device configuration. Conclusion.
SLIDE 4
4
Why BIST? What Else?
BIST widely used due to: Test time / Test cost improvements. Test quality improvements. Field testability. Reduction in chip test resources / tester infrastructure. Difficulties due to: Low coverage. Design intrusive implementation (timing, bounding, test points). Poor debug / diagnosis.
SLIDE 5
5
Why BIST? What Else? (2)
One-time manufacturing test increasingly inadequate: Need for periodic testing on field. Need for conformance checks for operating parameters. Insufficient screening with time zero tests. Solutions available: Online testing, e.g. compute time redundancy. Error correction, e.g. code space redundancy. Fault tolerance, e.g. module redundancy. Impact in terms of design overhead, fault coverage and error detection latency.
SLIDE 6
6
Scope of System Test
Covered faults: static / parametric. Test initiation: periodic / startup time. Test operation: online interleaved / offline. Test schedule: atomic / halt and resume. Test configuration: fixed / selectable. Test control: internal / tester interface / external. Test granularity: modular / entire chip. Test storage: RAM / ROM / Flash. Device state: destroyed / restored.
SLIDE 7
7
System Test Requirements
Enhancements to chip level BIST for system level test: Trigger mechanisms: Through test modes / application firmware running on CPU. Test configuration and interface: Through device internal test bus / external standard test / functional interface. Test control for various configurations. End of test status check and actions. Specific requirements for device and application / system test.
SLIDE 8
8
System Level Self-test
External host
- r interface
Master CPU DUT BIST - (Logic / Memory) Status registers Write Read microcode Self-test Internal memory (self-test config.)
SLIDE 9
9
Design Considerations for Logic Self-test
X tolerance / X handling – Functional and timing. Control of configuration and status registers. Test access
- protection. Test timeout – watchdog.
Internal clock control for high speed shift and at-speed capture. I/O pad control for quiescent system interface. Self-test control, indication and status.
SLIDE 10
10
Example: Internal Clock Control
Capture Pulses
Clock Dom 1 Clock Dom2
Scan-en dom 1 Clock dom 1
Aligned Capt ure Pulse Skew ed Last Shift Pulse
Ctrl clock Scan-en dom 2 Clock dom 2
last shift last shift -1
SLIDE 11
11
Self-test Architecture
Deterministic BIST (DBIST) with re-seeding is used. Modifications required to support self-test include: Internal re-seeding mechanism. Memory mapping, DUT - DBIST interface, DBIST – test interface control. Support for self-test: Pattern counter. Shift counter. Clock control: Device internal shift and capture. Internal signature storage and comparison.
SLIDE 12
12
Deterministic BIST Architecture
SLIDE 13
13
Logic BIST / Self-test Modules
BIST Progress Tracker Watchdog Timer Master Controller Read-Write Controller BIST Protocol Driver Configuration Register File Status Register file Test mode controller Hard Macros BIST Controller BIST Shadow Reg & PRPG Memory interface Unit RAM DESIGN UNDER TEST MISR Golden MISR Compare Unit S/W mode write I/F JTAG mode write I/F S/W mode read I/F JTAG mode read I/F Read I/F S/W mode write I/F JTAG mode write I/F ATE I/F
SLIDE 14
14
Procedure for Self-test
Reset deactivation Internal CPU activation Check self-test completion set to ‘1’ Load self-test S/W Into internal RAM Execute self-test routine DBIST run External host or CPU interface Execute functional instruction Pulse Internal reset Set “DONE” Status to ‘1’ Compare golden MISR 0 1 Pattern count =0 Seed count =0 YES NO YES NO NO YES Control by BOOTSTRAP
SLIDE 15
15
BIST and BISR for Memories
BIST for conventional reasons. Programmable BIST: For post-silicon encoding of (new) memory test algorithms. Support for non-functional sequences, e.g. single cycle access, back-to-back accesses, accessing groups of memory banks together. Online repair: Reduction in test data volume. Efficient analysis and allocation of spare resources. Reconfiguration (leading to graceful degradation). Implementation: Destructive test. Soft repair only. One memory type considered.
SLIDE 16
16
Design Considerations for Memory Test
Memory BIST activation mechanisms. Memory grouping for test. State of CPU and L1 / L2 caches. Fail data capture and analysis on chip: Tradeoffs in hardware
- verhead, analysis time, quality of repair solution.
Shifting new repair solution into memory address E-Fuse farm. Resumption of next phase of memory test after completion of earlier phase of repair.
SLIDE 17
17
Memory Test / Repair Architecture
CPU PBIST controller Datalog register MMR space E-Fuse Memory under test Data analyzer BISR repair solution shift clock Initial solution BISR
SLIDE 18
18
Procedure for Memory Test / Repair
CPU S/W for memory test algorithm PBIST run PBIST Done Failure ? Halt PBIST Log fail data New solution Shift repair solution Analyze data Repairable? Yes No No Yes Abort Memory set complete
SLIDE 19
19
Device Overview
2 IP cores and several other peripheral modules. Multiple clocks and frequencies. Peak 450 MHz operation.
Memory BIST controller Memory Self-test controller Peripheral interfaces Bus protocol manager ARM 9x core PLL / clock / test mode controller TI 64x DSP
SLIDE 20
20
Status and Summary
BIST and BISR implemented with different variations. Silicon validation complete. Methodology being replicated on other chips. Firmware development in progress. Scope extensions: Status restoration. Functional and structural tests. Profiling for reliability DPPM. “Online coverage of used logic” versus “Periodic coverage
- f all logic”.