Testability in EOCHL (and beyond…) Vladimir Zivkovic National Institute for Subatomic Physics (Nikhef), Amsterdam, The Netherlands FEI4_A review, 2-3rd November 2009 CERN, Geneve

Outline Introduction DfT Architecture DfT Flow Back-end Test Development Future Work

Functional vs Structural Testing Functional testing verifies that a circuit fulfils the desired spec. Functional testing not feasible for exhaustive tests. Example: 32-bit adder requires 265 ≈ 3.7*1019 test vectors Structural test focuses rather on the circuit structure and can cover manufacturing defects that otherwise may not have been detected by functional testing. Power or ground shorts Open interconnect on the die (caused by dust particles) Short circuited source or drain on the transistor, (caused by metal spike through) Functional testing verifies that your circuit performs as it is designed to perform. For example, assume that your design is an adder circuit. Functional testing verifies that your circuit performs the addition function and computes the correct results over the range of values tested. However, exhaustive testing of all possible input combinations grows exponentially as the number of inputs increases. To maintain a reasonable test time, you need to focus functional test patterns on the general function and corner cases. Manufacturing testing verifies that your circuit does not have manufacturing defects by focusing on circuit structure rather than functional behavior. Manufacturing defects include problems such as Power or ground shorts Open interconnect on the die caused by dust particles Short-circuited source or drain on the transistor, caused by metal spike-through Manufacturing defects might remain undetected by functional testing yet cause undesirable behavior during circuit operation. To provide the highest-quality products, development teams must prevent devices with manufacturing defects from reaching customers. Manufacturing testing enables development teams to screen devices for manufacturing defects. Typically, development teams perform both functional and manufacturing testing of devices.

Scan Chain DfT Principle   Scan Chain DfT Principle

Outline Introduction DfT Architecture DfT Flow Back-end Test Development Future Work

Digital Testing Framework 0110 1000 1011 0001 : comparators fail flags Device Under Test (DUT) stimuli 0001 0111 1010 : response Stimulus and response calculated by Automatic Test Pattern Generator (ATPG) based on fault models Computed on the whole device or on parts of the design, so-called embedded IP’s (cores) Access to embedded terminals of the IP through design for test (DfT) is necessary Digital testing is real time pass/fail testing. As can be seen from the figure, patterns of ‘0’ and ‘1’ are applied to the DUT. Since a digital circuit is deterministic, which means it has a complete definable set of input-output states, it can be tested by comparing the resulting patterns against a pre-computed compare patterns, cycle by cycle. If any bit fails, the complete device fails.

Generic Test Access Architecture wrapper 3. Core Test Wrapper IP IP source sink 1. Test Pattern Source and Sink TAM 2. Test Access Mechanism (TAM) TestRail [ Zorian, Marinissen, Dey - ITC’98 ] IP = {EOCHL, CMD, DOB, EODCL}

Wrapper Isolation Overview Mandatory Wrapper cells providing function access and test controllability + observability at IP’s data terminals bypass bypass IP TestRail inputs TestRail outputs TestRail access to wrapper cells (‘surround chains’) and IP flip flops (‘scan chains’) Wrapper Control Block function inputs function outputs Optional Bypass register for all TestRail chains Wrapper Control Block + anti-skew element

How does this reflect to our situation? Insert wrappers around EOCHL, CMD and other blocks with scan chains (DOB, EODHL) Primary TRO_cmd[0:2] TRI_eochl[0:2] IC LEVEL Wrapper Control Block Wrapper CMD EOCHL scan chain 0 (1700 FFs) scan chain 1 (400 FFs) CMD scan chain 0 (3000 FFs) scan chain 1 (600 FFs) Wrapper Control Block Wrapper EOCHL Top level Test Control TRO_eochl[0:2] TRI_cmd[0:2] Inputs from other digital blocks, e.g. EODCL, CFGMEM Outputs to other digital blocks, e.g. EODCL, CFGMEM Inputs from other digital blocks, e.g. EODCL, CFGMEM

Wrapper + Top Level Control Blocks will be scan-tested independently, i.e. in isolation of each other Top-level test control (scan enable, test mode selection) have to be implemented for each block Courtesy of M. Garcia-Sciveres *

Wrapper Isolation Cells Provide the application of the test stimuli at the embedded IP inputs as well as the observability at the embedded IP outputs

Wrapper Cells in the Nutshell Input isolation Output isolation Note: Only the combinatorial inputs require isolation

Outline Introduction DfT Architecture DfT Flow Back-end Test Development Future Work

Two-pass Synthesis or mapped flow

Synopsys DfT Compiler Listings Library Control Script (.tcl) Test Constraints (.tcl) Library Synopsys DfT Compiler Netlist (.v) Synopsys Internal databasel STIL/CTL test protocol Scannable Netlist (.v) Listings

DfT Procedures in the nutshell PROC_dft_insert_init Global setup for dft insertion PROC_read_design Reads netlists and libraries and builds the design PROC_create_protocol_for_test Invokes the test constraints and builds the test protocols PROC_insert_scan Insert scan chains (preview_dft and insert_dft) PROC_handoff_design Write result to verilog, db, and test model (STIL/CTL) files

Scan Chain reports for the EOCHL 1 scan chain, length= 2927 Standard DfT signals: si, so, se Clocked with an additional test clock (tck) –clock gating with functional clocks performed at the top level of the IP Additional DfT signal tm (to enable the test clock)

ATPG flow A plan is to use Synopsys TetraMax ATPG tool This flow has to be executed at the design level containing EOCHL, CMD and wrapper isolation

Test Patterns The TetraMax ATPG is expected to generate the following: Continuity test patterns To check the scan chain structures themsleves, typically 11101000 sequence is shifted through Scan chain patterns for stuck-at faults Optionally: IDDQ patterns Transition/Path delay fault patterns Bridge patterns

Outline Introduction DfT Architecture DfT Flow Back-end Test Development Future Work

Test Assembly Process The main purpose is to: Assemble the test patterns of the IP(s) in the IC Convert these patterns into the real test vectors Generate the test bench for the simulation with both stimuli and response Include the timing and wave information

Back-End Test Development Flow DfT Abstractions Test patterns test lib waveform generation functional test Test Assembly tester specific vectors test bench Simulator netlist behavior models

Test Setup DUT Wafer Test ATE, Test Setup Lab Setup

Future Work concerning the test development flow with scan chains Create the Wrapper around CMD and EOCHL blocks Run the ATPG at this level Back-end test development Link to lab setup Link to tester vectors running at tester platform (Verigy? Teradyne? Or … ?) Mixed-Signal Test