Method for automating validation of integrated circuit test...

Error detection/correction and fault detection/recovery – Pulse or data error handling – Digital logic testing

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

Reexamination Certificate

active

06553524

ABSTRACT:

FIELD OF THE INVENTION
The presented invention relates generally to the use of test logic hardware to prove out integrated circuit design and, more particularly, to a method for automatic validation of integrated circuit test logic.
BACKGROUND OF THE INVENTION
The soundness of the logic design of an integrated circuit (IC) device or part must be tested prior to actually manufacturing the hardware. This is especially true of extremely complicated and exceedingly dense ICs, such as complex central processor units (CPUs) and microprocessors, which may have close to a billon transistors. Now in order to be able to observe the minute details of the inner workings of such extremely complex devices after manufacture, appropriate test circuitry, in addition to the other functional pieces of logic hardware, needs to be designed inside of the chip during the design phase of the chip.
Unlike major functional blocks of the chip, such as an integer block or a floating point block whose die location can be precisely determined, however, the entire test hardware of the chip is composed of a great number of serially connected test components called scan latches that are scattered through the chip to ensure that observability and controllability are provided for each and every portion of the chip.
FIG. 1
illustrates a sample scan latch composed of a test latch portion electrically coupled to a functional portion, as indicated by the dashed lines. It can be seen that the test latch portion is provided with test data input, TDI, which can be provided locally to the scan latch, and controlled by various test signals, such as SHIFT, NSHIFT, LOAD (WRITE), and UPDATE (READ), to capture functional data OUT and output test data output (TDO), which is in turn provided to the functional latch portion. The functional latch portion is controlled by a qualified clock signal, CKQ, which in turn is controlled by an appropriate test signal (not shown here) to ensure that the output signal OUT of the scan latch is controlled by TDO (via the WRITE test signal) when the IC chip is in the test mode and by the IN data input in the normal operating mode.
In the normal operating mode, WRITE test signal is OFF while CKQ fires. If the WRITE test signal does not fire, the functional and test latch portions perform independently. The normal data, IN, is passed through to the output signal OUT in the normal operating mode. Conversely, in the test operating mode, firing the WRITE test signal controls the output signal OUT. The UPDATE (READ) status signal transitions to read in the captured data OUT and the SHIFT and NSHIFT signals shift TDI into the scan latch and also transfer captured data OUT through the scan latch. The WRITE test signal fires, thereby transferring the local test data out TDO to the functional latch.
The test signals, such as SHIFT, NSHIFT, LOAD (WRITE), and UPDATE (READ), that are used to control the operation of the scan latches are produced from a single test control block, called a test access port (TAP), which can control operation of the entire test hardware of the chip. Often, however, the overall control of the test hardware scan latches is broken down between smaller test control blocks, called mini test access ports (MTAPs), that are each centrally controlled by a single, and much simpler, TAP. Each MTAP provides data and test signals to a series of scan chains or scan paths that are connected in parallel. Each MTAP, and its corresponding scan chains, may typically be dedicated to testing a particular functionality of the chip. To this end, it is not uncommon to have a particular MTAP and set of scan chains dedicated to a particular functional block, such as a floating point block, for instance. There is no requirement, however, of a one-to-one correspondence between MTAP/scan chains and functional block. Thus, each block, or sub-block, or functional piece of the IC chip may have two or more MTAP/associated scan chains combinations.
An illustration of such a distributed test architecture is shown in FIG.
2
. As previously mentioned, the scan latches that make up the test hardware of the chip are organized as serially connected test components. Related scan latches that are used for testing a particular functional piece of the IC device, such as a particular type of block or a functional sub-block of a block, are serially arranged in a particular scan path; multiple scan paths of a particular MTAP are connected in parallel to one another. The TAP is provided with various input test signals, shown here as TRST (test reset), TCK (test clock), TMS (test mode select), TDI (global), and TDO (global). The global data and test signal are provided to each of the MTAPs by the TAP. Each MTAP, in turn, provides its corresponding scan paths with local normal and test input data and test signals appropriate to the particular block, sub-block, or functional bit of the IC chip they are serving. The local test results are provided by the scan paths back to their particular MTAP, which in turn provides the test data back to the TAP over a global connection. It is noted here that global as used herein refers to signal communications between the TAP and the MTAPs, typically across functional blocks of the IC chip. Typically communications between MTAPs and their scan paths will occur within a functional block of the IC chip and thus be local in nature.
FIG. 3
illustrates the serial connection of two scan latches in a simple scan chain; of course, an IC chip will have thousands or more such serially connected latches in a scan chain. In a scan chain or scan path, normal input data NDI and test input data TDI, as well as test signals, such as SHIFT, NSHIFT, LOAD (WRITE), and UPDATE (READ), will be provided to the initial scan latch. Depending upon whether the IC is in the normal operating mode or the test operating mode, the initial scan latch will pass along the appropriate type of data to the next scan latch in the scan chain via logic circuitry by which contiguous scan latches in the chain can communicate.
It is current practice in the art for a chip design team to spent a great amount of time adding a few extra pieces of hardware to obtain specific performance benefits and/or to port or re-layout an existing design to a new manufacturing process in order to improve performance. Although this means that most blocks are virtually untouched in terms of any change in functionality, this is not true for the test hardware. Any new hardware that is added will need to have test circuitry in the form of scan latches built inside it to be able to observe and control certain critical functional signals during the debug and characterization phase of a chip after it has been manufactured. These scan latches will then need to be serially connected to each other and also to the global scan chains described above. The appropriate test signals will need to be routed over to the new piece of test hardware from the test control blocks (TAP and MTAPS). Any porting of an existing design to a new manufacturing process causes metal routes to be relocated and replaced with faster metal layers, thereby causing the occasional opens, shorts and faulty connections in global test signals and in functional signals. And for purely functional signals, possible problems are found during functional verification of the chip, as well as or in addition to, during static or dynamic timing analysis of the chip. But the validation of test signals and test hardware requires a whole new effort because the test hardware is almost always very simplistically modeled in global functional verification runs that tend to focus on strictly design (not test) issues and is also almost always generally ignored in global static/dynamic timing runs. Since the test control blocks (TAP and MTAP) are almost untouched, except for porting the design to a new manufacturing process, etc., the validation effort on test hardware should focus heavily on having the correct connectivity of the test signals to the scan latches themselves. Also, electrical quality of the

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Method for automating validation of integrated circuit test... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Method for automating validation of integrated circuit test..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for automating validation of integrated circuit test... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-3060414

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.