Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Multiple LBIST Fails Diagnostic Test Data Acquisition Method

IP.com Disclosure Number: IPCOM000033398D
Original Publication Date: 2004-Dec-09
Included in the Prior Art Database: 2004-Dec-09
Document File: 3 page(s) / 60K

Publishing Venue

IBM

Abstract

Disclosed is a method for identifying multiple failing test in an LBIST design utilizing Signature Analysis techniques. The basic concept provides the ability to generate unique and independent signatures for each test cycle. This is achieved by repeatedly enabling system clocks for individual test cycles.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Multiple LBIST Fails Diagnostic Test Data Acquisition Method

A problem often encountered in LBIST testing and subsequent diagnostics is the need to identify multiple failing tests and collect the associated failing test results. Identifying the first fail in a given test sequence is readily performed using traditional ATE programs and methods. In attempting to identify multiple LBIST fails in a signature interval, however, traditional methods break down. Due to the nature of the LBIST signature analysis (SA) techniques, in which the test result of each succeeding test cycle is continuously updated and compressed into the cumulative signature, any failure after the first fail becomes difficult to identify.

The method's implementation consists of three distinct process phases as shown in flow of Fig. 2:

Independent signature generation for each test cycle.

Dumping the logic state of the device for all failing test cycles.


1.


2.


3.

The first phase generates the independent signatures for each test cycle by suppressing the system clocks for all preceding test cycles as shown in Fig. 1. These signatures could be obtained on-the-fly using a "good" device to bootstrap the expected signature on the tester. An alternate approach to generate the signatures could be via off-line simulation. In either case, the signature generation test sequence must be the same as the sequence applied during the actual test of the failing device. The number of Good Machine Simulation (GMS) signatures needed depends on the failing properties of the defective Device Under Test (DUT) and the number of desired failing test cycles. Of course, the higher the number of cycles applied and the higher the number of failing cycles data collected, the higher the diagnostic resolution that can be achieved.

The second phase describes the test flow once the expected signatures per tester loop are generated. The test system can use these signatures to compare them to the defective's device actual signatures and determine the failing test cycles. Similarly, the test application sequence must be the same as the signature generation sequence, i.e. the tester must suppress the system clocks to the DUT for all test cycles preceding the test cycle of interest. This sequence is then repeated until the desired number of failing cycles is obtained. The tester...