Technical Proposals for IEEE P1500 Core Test Standardization Erik Jan Marinissen Research Laboratories Eindhoven, The Netherlands P1500 Meeting ITC Test Week, Washington D.C., November, 1997 Technical Proposals for IEEE P1500 Core Test Standardization 2 Outline 1. Introduction 2. Core Test 3. IEEE P1500 Standardization 4. Proposal for Scaleable Architecture Test Access Test Control 5. Proposal for Core Test Description Language 6. Vision for the Future 7. Conclusion
Core-Based Design Increase in design productivity through reusable embedded s (intellectual property megacells, system-level macros, virtual components). Hard, Firm, and Soft s. Intra-company and inter-company reuse. Intellectual Property Rights (R) protection. Core-based design: definition of requirements and standards to make reuse easy (plug& play). Core-based design divides the design community into (1) providers and (2) users. (1) Introduction 4 Core-Based Product Creation Process X X3 X2 X1 X0 spec X0 X1 X3 X2 development provider,! customization & packaging integration,! user
Core Test Prevent test from being the bottleneck in -based design. Enable easy integration of s w.r.t. testing (plug&play). Support and promote reuse of -level tests. Definition of requirements and standards: intra-company guidelines ( CTAG) inter-company worldwide standards (VSI Alliance, IEEE P1500) (2) Core Test 6 How to recognize a sound Core Test strategy? Enables easy integration of s w.r.t. testing. Supports Reuse of tests as provided by the provider. All types of tests: function test, scan test, BIST, memory test, IDDQ test, interconnect test. Hierarchy: today s ICs are tomorrow s s. Automated expansion of test to chip level. Multiple clock testing within one and between s. Cost-effective w.r.t. area, pins, test time, performance, power.
Core Test vs. Board Test Core-based design is the next step in on-chip integration: what used to be components on a board are now s on an IC. Board test is solved : IEEE 1149.1 (JTAG) Boundary Scan. JTAG solves the problem of testing the interconnects between components. Testing the components itself via JTAG is extremely time consuming, but at board level components are tested by their manufacturer and hence assumed defectfree. In -based designs, the has not yet been manufactured, and hence not yet been tested for manufacturing defects. Testing the interconnects between s is important, but testing the s internally is at least as important. JTAG provides learning material for P1500. However, JTAG only does not provide a solution for test. (3) IEEE P1500 Standardization 8 P1500 Task Forces Scaleable Architecture - Lee Whetsel DfT between module and host to enable plug&play. Test access: define access with variable width. Test control: define minimum, allow for extensions. IEEE 1149.1 TAP should fit the standard. Core Test Description Language - Ken Wagner Standard language to describe all test aspects of an module. Data interface between provider and user. Syntax based on IEEE P1450 (STIL)?
Proposal for Scaleable Architecture s test is supplied by provider. Every is wrapped in a TESTSHELL by the packager. Test for only needs TESTSHELL around it. It does not rely on other s. TESTSHELL test access to module: TESTRAIL interconnect test: boundary scan ring around module test control: Test Control Block (TCB) Core user is responsible for proper connections of TESTSHELLs and translation of -level test into chip-level test. (4) Proposal for Scaleable Architecture 10 TestShell introduces three layers of hierarchy level DfT responsibility 1. provider 2. provider/user 3. host user host TestShell A TestShell B takes care of test access test control := + TESTSHELL
Test Access via the TESTSHELL TESTSHELL is transparent in normal mode. Test access preferably via the TESTRAIL. TESTRAIL handles all synchronous digital tests: functional, scan, BIST, memory, etc. TESTRAIL width is variable. TESTRAIL has bypass mode. Only if necessary, direct access to host terminals is provided: clock signals, asynchronous signals, analog signals. (4a) TESTSHELL: Test Access 12 Test Access via the TESTSHELL function input function output direct test input TestRail input direct test output TestRail output function input function output n bypass n test stimulus intercon. response intercon. stimulus test response external internal
Host-level TestRail connections host Cores can have their private TESTRAIL, or TESTRAILs can be concatenated. 16 Core A 16 16 16 TESTRAILs can fork out, or merge together. 10 16 Core D Core B 2 16 Core C 16 Core E Core F 10 TESTRAIL inputs/outputs can have private pins, or various TESTRAILs can be multiplexed. 8 TESTRAIL inputs/outputs can be multiplexed with functional pins. (4a) TESTSHELL: Test Access 14 n Core A Core B Core C IC n Test of B Stimuli and responses via TESTRAIL. TESTRAIL B in test mode. TESTRAILs A and C in bypass mode. n Core A Core B Core C IC n Interconnect test Stimuli and responses via chip pins and TESTRAIL. JTAG-like interconnect test. TESTRAILs allsin interconnect test mode.
Shell-level TestRail connections decompression compr. compr. 1. parallel 2. serial 3. compressed Trade-off between - required bandwidth (test data volume: test time), and - available bandwidth (width of TESTRAIL: pins, area). Decompression at inputs only for regular stimuli (memory test). Compression at outputs always possible (MISR, XOR tree). (4a) TESTSHELL: Test Access 16 Shell-level TESTRAIL connections Example 1: Scan test Characteristics Large test data volume on scan inputs/outputs. Small test data volume on non-scan inputs/outputs. TESTRAIL connection Inputs parallel serial (non-scan inputs) concatenated (scan chains) Outputs parallel serial (non-scan outputs) concatenated (scan chains) compressed typical example scan chain scan chain scan chain scan chain
Shell-level TESTRAIL connections Example 2: Built-in self test Characteristics Small test data volume (only initialization + signature). TESTRAIL connection Inputs / Outputs parallel serial typical example decompression compression (4a) TESTSHELL: Test Access 18 Shell-level TESTRAIL connections Example 3: Synchronous function test Characteristics Large test data volume on all inputs and outputs. Test patterns should be applied in specified order at consecutive clock cycles. TESTRAIL connection typical example Inputs parallel serial with clock holding at Outputs parallel serial with clock holding at compressed
TestRail width Negotiable between provider and user. Core user: host-level considerations Test time: relative test data volumes of all s, sequential vs. parallel testing. Pins: number of available host terminals. Area: wiring of inter- TESTRAIL. Core provider: -level considerations Hard with fixed number of scan chains. Small test data volume does not require a wide TESTRAIL. Core provider may offer a product catalogue with a few TESTRAIL widths per available. (4b) TESTSHELL: Test Control 20 TCBs at three hierarchy levels 1. TCB Responsibility of provider. Standard should be able to handle s with and without TCBs of all types. 2. Shell TCB Joint responsibility of provider & user. Generates test control for TESTSHELL modes: function, test, interconnect test, bypass; module (if required). 3. Host TCB Responsibility of user. Overall host-level test control.
host TCB TCB A A host TCB TCB B B Shell TCB and host TCB are slice TCBs. Shell TCB and host TCB are loaded via one scan chain. Shell TCB can also generate test control signals for module. (4) Proposal for Scaleable Architecture 22 Testing between s Interconnect wires + buffers + inverters interconnect test ( 2 log N patterns), apply via TESTSHELL and TESTRAIL Glue logic combinational + sequential logic full scan design + C-ATPG, apply via TESTSHELL and TESTRAIL User-Defined Logic (UDL) treat larger UDL modules as s wrap UDL in TESTSHELL, connect to TESTRAIL test UDL as independent
Proposal for Core Test Description Language Base CTDL s concept on separation of test protocols and test patterns. This reduces the compute complexity for test (protocol) expansion, and test (protocol) scheduling Extensions for sub clock cycle timing, multiple clocks, algorithmic patterns, expansion through FSMs, etc. Support hierarchy by defining one language both for and host level. In that way, a host can serve as again. Specific syntax is not (yet) important; base CTDL on existing language such as STIL(++?) (5) Proposal for Core Test Description Language 24 IC Application Specific Hardware DSP CPU Embedded DRAM Xdata mem DIO Xaddr ALU APU Yaddr ALU Ydata mem SRAM logic logic SRAM BIU logic logic logic Xbus Ybus Cbus MPI PCU LCU logic Reg. Bank register file logic logic Instruction Cache DRAM
Test := Test Protocol + Test Patterns pattern file 0001010101000101101101010 PAT 0101000111010101000101010 0001010100101010001011101 0101010001001011101010100 0010111010111010101110110 1110101001001001001001110 0010010010001001111010101 1010100111010111011101110 1101010010010010011101010 sc 1 1 1 1 1 1 1 1 1 1 x 0 m 0 a 1 1 1 1 1 1 0 1 1 1 1 1 1 si0 S 0 S 1 S 2 si1 S 3 S 4 S 5 S 6 S 7 S 8 y o1 S 9 R 10 so0 so1 R R R 11 12 13 R R R R 14 15 16 R R 17 18 19-11-10-9 -8-7 -6-5 -4-3 -2-1 0 1 2 3 4 5 6 TEST ASSEMBLY TEST (6) Vision for the Future 26 Vision for the Future Vivid IC design and manufacturing, based on reusable s. Core providers offer a catalogue of various s distinguish themselves not only by functionality of the modules, but also by ease of integration features, a.o. in test have customization and packaging departments, that deliver modules packaged in the P1500 TESTSHELL, and with the P1500 CTDL files offer a range of TESTRAIL widths and TCB structures.
Vision for the Future (cont d) Core users select s from a wide variety of providers, not only on functionality of the module, but also on ease of integration features, a.o. in test determine chip-level test strategies w.r.t. pins, routing area, test time, etc. take care of test protocol expansion and scheduling CAT vendors offer and compete with second generation CAT tools tools for optimal TESTSHELL wrapping and connecting tools for test protocol expansion and scheduling (7) Conclusion 28 Conclusion Core-based design is about design efficiency through reuse. Hence, test should be about design and test efficiency through reuse. Inter-company test creates the need for an international standard. Proposal to Scaleable Architecture Task Force: Every wrapped in TESTSHELL. Test access preferably via extendable TESTRAIL. Test control by extendable Test Control Blocks. Proposal to Core Test Description Language Task Force: Separate test into test protocol and test patterns. Support hierarchy by defining one language.