EECS 579: SOC Testing

Size: px

Start display at page:

Download "EECS 579: SOC Testing"

Evelyn Thomas
5 years ago
Views:

1 EECS 579: SOC Testing Core-Based Systems-On-A-Chip (SOCs) Cores or IP circuits are predesigned and verified functional units of three main types Soft core: synthesizable RTL Firm core: gate-level netlist Hard core: fixed layout Key feature: reusability, implying lower design cost Core is the intellectual property of the vendor. Usually internal details are not available to users Test from core vendors must be applied to embedded cores John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 1 Core Examples Processors: ARM, MIPS, PowerPC Memories: RAMs, memory controllers Peripherals: Bus interface units (PCI, USB, etc.), DMA controllers Multimedia: compression/decompression circuits (MPEG, JPEG, etc.) Digital signal processors John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 2

2 Core Examples VBAFE PCM RAM ROM Oak DSP processor ADC FIFO PLL Timer Viterbi Reg. file JTAG ICE DMA Exchange breaker controller buffer MMU UART RTC Mode conf. reg. IT & Timer Boot CSGEN ARM7 processor Cache Timer Trans PID processor Discrambler Cache controller MIPS processor Parallel port DRAM controller A/V buffer Teletext Serial port GSM wireless communication chip MPEG2 audio/video decoder chip John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 3 SOC Testing Partition into blocks according to test methodology: processors, memories, peripherals, etc. Introduce test access mechanisms such as boundary scan (IEEE ) or analog test bus (IEEE ) Place test-wrappers (collars) around embedded cores. For each I/O terminal a test wrapper provides: Normal mode: terminal driven by core and/or host External test mode Wrapper controls/observes terminal for interconnect test Internal test mode Wrapper observes/controls state terminal for core test John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 4

3 Test Wrapper Wrapper elements Functional core inputs Scan chain Core Scan chain Functional core outputs To/from external Test pins Scan chain To/from Test Access Port Wrapper test controller John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 5 DFT Architecture for SOC Test source Functional inputs User defined test access mechanism (TAM) Test Module 1 wrapper Fcn outputs Fcn. inputs Test Instruction register control Module N wrapper Test sink Functional outputs Serial instruction data Test access port (TAP) SOC inputs TDI TCK TMS TRST TDO SOC outputs John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 6

4 Motivation Realization-Independent ATPG To efficiently test SOC-style core-based designs Generate tests with a high degree of independence of implementation and technology details Protect IP by generating tests from the circuit s functional spec. Reduce the need for boundary scan and speed up test application Approach 1: Cell Fault (CF) Tests Uses exhaustive input pattern and responses sets Covers all implementations but is practical only for tiny cells Approach 2: Universal Test Sets John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 7 Universal Test Sets The universal test set (UTS) U z of z consists of all minimal true T F expanded vectors U z and all maximal false expanded vectors U z of z (Expanded vectors include all literals appearing in a function s minimal expression.) Minimal true vectors {t i } of a function z are such that z(t k ) = 1 for all t k t i, but z(t k ) = 0 for all t k < t i. Maximal false vectors are defined similarly. If z is a unate, its UTS is quite small. (A function z is unate if all its variables appear in minimal two-level expressions only in complemented or uncomplemented form.) If z is not unate (binate), its UTS increases in size up to 2 n tests John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 8

5 Universal Test Sets The UTS detects all MSL faults in a circuit R meeting the following restriction: every path between two points in R has the same inversion parity; these realizations are called unate-gate networks. This result is easy to prove for unate functions since an SSL or MSL fault changes a unate-gate network to another unate-gate network The UTS for unate z can be constructed by substituting 1 for every variable in each prime implicant of z, and substituting 0 for every variable not present, while substituting 0 for every variable in each prime implicate and 1 for every variable not present. UTS detects all multiple stuck-line (MSL) faults in a gate-level implementation of z that meets modest constraints, e.g. unate-gate networks John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 9 Universal Test Sets Example 1 Consider z 1 = ab + ac + bcd, which is unate in a,d but binate in b,c Input vectors abcd Expanded vectors abbccd Output z 1 Universal tests Max. false Max. false Max. false Min. true Min. true Min. true Min. true Max. false a b c d Universal test set: 0: : : : : : : : 1110 z 1 John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 10

6 Universal Tests Example 2: Carry Function Carry functions are positive unate In carry-lookahead form, the 4-bit carry function is as follows in (minimal) SOP and POS form: c 4 = p 0 p 1 p 2 p 3 c in + g 0 p 1 p 2 p 3 + g 1 p 2 p 3 + g 2 p 3 + g 3 = (g 3 + g 2 + g 1 + g 0 + c in )(g 3 + g 2 + g 1 + g 0 + p 0 ) (g 3 + g 2 + g 1 + p 1 )(g 3 + g 2 + p 2 )(g 3 + p 3 ) The corresponding 10 tests are: U T (p 3,g 3,p 2,g 2,p 1,g 1,p 0,g 0,c in ) = { , , , , } U F (p 3,g 3,p 2,g 2,p 1,g 1,p 0,g 0,c in ) = { , , , , } The UTS for c 4 is {U F,U T } John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 11 UTSs vs. CF Tests Universal Tests Number of tests Building blocks Inputs Outputs Universal Cell fault Carry generator Carry generator ,1072 Leading zero detector Leading zero detector ,536 Priority encoder Priority encoder ,072 Booth partial product Decoder with enable John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 12

7 Realization-Independent Block Tests Key Ideas Apply universal tests to small functional (RTL) blocks of large circuits Implement the blocks as balanced-inversion parity (BIP) circuits: paths from all unate variables have the same inversion parity Many blocks in datapath circuits are (nearly) unate and have small universal test sets Need to resolve controllability/observability problems of embedded blocks Reference [Kim & Hayes, IEEE Trans. CAD 2001] John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 13 Circuit Constraints Balanced inversion-parity (BIP) Paths from unate variables have same inversion parity Covers almost all practical implementations Unate-gate network a a BIP realization b c d z 2 b c d z 2 John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 14

8 Realization-Independent Block Tests n For the entire adder n (2N +1) l Universal tests = 2 For a block-structured adde l Universal tests N = + 24 A B A B Adder p i = a i + b i, g i = a i b i c in p i = a i + b i g i = a i b i c i = g i 1 + p i 1 c i 1 s i = p i g i c i c in c i = g i 1 + p i 1 c i 1 s i = p i g i c i n S Block-structures lead to small universal test S John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 15 Realization-Independent Block Tests a 0 b 0 a 1 b 1 a 2 b 2 a 3 b 3 PGB Ripplecarry adder C in p 0 g 0 p 1 g 1 p 2 g 2 p 3 g 3 p 0 g 0 c 1 p 1 g 1 c 2 p 2 g 2 c 3 p 3 g 3 CB SB C out a 0 b 0 s 0 s 1 a 1 b 1 a 2 b 2 a 3 b 3 s 2 s 3 PGB Carrylookahead adder C in p 0 g 0 p 1 g 1 p 2 g 2 p 3 g 3 CB C out p 0, g 0 c 1 p 1, g 1 c 2 p 2, g 2 c 3 p 3, g 3 SB s 0 s 1 s 2 s 3 Fig 1: John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 16

9 Realization-Independent Block Tests Apply all universal tests to every block Observe all responses from every block, if possible All universal tests {t i } All faulty responses {r i } a b c d Block 1 x 1 = a + b x 2 = abc x 1 x 2 Block 2 y 1 = (x 2 + x 1 )(d + x 2 ) y 2 = x 1 + x 2 y 1 y 2 Block 3 z 1 = d(y 1 + y 2 ) z 2 = y 1 + y 2 + d z 1 z 2 John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 17 Realization-Independent Block Tests RIB (realization-independent block) tests Detect all faults even when non-applicable tests occur Fast RIB test computation Replace the non-applicable tests in the universal test set New tests are always at Hamming distance 1 from the non-applicable tests Add only a minimal number of new tests RIB fault model Any fault <t i, r j > causing r j when RIB test t i is applied John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 18

10 RIBTEC Program Input: behavioral Verilog code Generate initial universal tests Compute t RIBTEC by high-level PODEM (<t i, r j >) Failure Compute RIB tests for non-applicable vector t i No Drop other faults by FSIM All RIB faults detected? Yes Success Output: RIBTEC test vectors John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 19 RIBTEC Program Procedure RIBTEC(C) /* C = circuit and B = block */ 1:for each B repeat U(0) := UTgen (B);/* Initial UTS generation */ 2:S P := all pairs {(t i, r j )} for all t i s in all U(0) and all faulty responses r j s; 3:while (S P is nonempty) begin 4: Select pair (t i, r j ) for block B from S P ; 5: pt := HL-PODEM( (t i, r j ) );/* Compute pt via high-level PODEM */ 6: if (no pt exists) then /* t i is an NCV or NOV */ 7: T R := RIB-Tgen (t i, U(k)); k := k + 1; 8: S P := S P {new pairs (t h, r y ) derived from T R }; 9: if (t i = NCV) then S P := S P {(t i, r j ) for all j}; 10: else S P := S P (t i, r j ); 11: else 12: T RIBTEC := T RIBTEC {pt};/* T RIBTEC = the final test set */ 13: FaultSimulate (pt, S P );/* Find other covered pairs {(t i, r j )} in S P */ 14: S F := S F {all covered (t i, r j )};/* S F = the detectable RIB fault set */ 15:end; 16:Reverse-Order-FaultSimulate (T RIBTEC );/* Perform test compaction */ 17:return T RIBTEC and S F ; John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 20

11 Experimental Results RIBTEC Program Benchmark circuit Atalanta tests for high-speed realization Detectable RIB faults RIBTEC tests for high-level design NCVs and NOVs RIB fault coverage Number of tests CPU time (sec.) Atalanta tests for low-area realization RIB fault coverage Number of tests RIB fault coverage Number of tests 16-bit CLA % % % bit CLA % % % bit CSA % % % bit CSA % % % bit ALU % % % bit ALU % % % bit comparator % % % bit comparator % % % 213 c880 8-bit ALU/controller % % % 160 c bit adder/ comparator % % % 124 John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 21 Summary High degree of realization independence is possible with fairly small test sets Modular (partitioned) structure is useful in conjunction with special properties like unateness Approach provides a high-level ATPG tool (RIBTEC) and a functional, realization-independent fault model Seems promising for testing IP-based designs John P. Hayes University of Michigan EECS 579 Fall 2001 Lecture 24: Page 22

Hardware testing and design for testability. EE 3610 Digital Systems

EE 3610: Digital Systems 1 Hardware testing and design for testability Introduction A Digital System requires testing before and after it is manufactured 2 Level 1: behavioral modeling and test benches