2008 asts technical paper protocol aware ate submitted

Protocol Aware ATE

Eric Larson Teradyne

30701 Agoura Road Agoura Hills, Calif USA 91301

Biography

Eric Larson has more than 28 years of experience working at Teradyne in roles ranging from Factory Applications Engineer to Field Product Specialist, and Technical Marketing. Eric has been involved with supporting Teradyne’s Logic and SOC test systems from J283 through Catalyst and UltraFLEX. He currently works in the Broadband, Computing, and Storage (BCS) Business Unit focusing on Digital testing, both high speed and DFT.

Abstract: Modern semiconductor devices often behave in a non-deterministic manner not only in their end application but during test execution on ATE as well. This is the result of design methodologies that allow the assembly of the device from a library of IP blocks. These IP blocks often support specific industry standard protocols such as JTAG, DDR memory buses, PCI Express, etc. While the operation of any individual block may be predictable the timing relationship between protocols often is not. Today’s SOC ATE does not deal well with ambiguity. Any deviation from expected device behavior will cause that device to fail ATE test, both during engineering development or production. Functionally testing devices that exhibit non-deterministic behavior is extremely difficult on current generation ATE.

This paper describes a proposed solution to deal with non-deterministic device behavior, a new ATE architecture - Protocol Aware ATE (PA-ATE). Specifically covered will be some of the problems currently faced by Semiconductor ATE users and the usefulness of Protocol Aware ATE to address those problems.

As described by Andy Evans of Broadcom, protocol Aware ATE is an:

“ATE Architecture which can natively emulate real time chip I/O at the Protocol Level.

Enables testing a device [with methods] ranging from using a single chip interface to total “Mission Mode”, at the highest level of abstraction centric to the interfaces specific protocols.” [1]

1. Introduction SOC device operation is often non-deterministic in the end application (mission mode). Devices seamlessly communicate and handshake to establish operating parameters such as data timing and operating frequency. This capability, while perfectly acceptable and necessary in the customer application can cause serious problems during ATE test. Among the reasons for non-deterministic behavior in a test environment are: - Multiple time domains with no frequency relationship - Asynchronously linked buses with an independent PLL

per time domain - I/O buses using many different complex protocols and

clocking schemes - Different behavior across Process, Voltage, and

Temperature (PVT) including shifts in timing, insertion of idle cycles, and changes in data order

Current stored response ATE architectures can only deal with deterministic behavior during test. As a result - Test development time is long because of the

difference in Device Under Test (DUT) behavior in design and ATE

- Fault coverage is inadequate because the DUT is not tested in “Mission Mode” (end application)

- Test times are long because multiple pattern executions are required looking for a pass or the DUT output must be captured and post-processed

- Early silicon yield is reduced because good devices don’t match ATE pass conditions

This problem is becoming more pervasive. The semiconductor design community has a rich set of proprietary and commercial tools available to simplify and speed up device design. - Design teams develop full feature designs faster using

Asynchronous IP that speeds design time and chip timing closure

- Designers work with high level behavioral simulations, simplifying verification of complex bus protocols.

The test community is not so fortunate - Test Engineers do not have re-usable Test IP

2008 Beijing Advanced Semiconductor Technology Symposium


- Behavioral level simulations (event based) must be converted to vectors (time based). Test engineers must debug with low level vectors - ’01HLX’.

- Asynchronous Interfaces cause non-determinism, which test engineers must try to predict and adjust for in the timing and vectors (may shift with Process Variation).

The device design methodology and behavior described above causes a number of problems for the test community. When operating in the end application (mission mode) many devices require some sort of interaction to: - Establish communication parameters such as bus speed

and width. - Set up internal register states for proper operation - Load up internal memory (SRAM, DRAM or Flash)

with information required for the device to properly operate, sometimes referred to as boot code

This device-to-device interaction often involves two-way handshaking. One device will send information and wait for the other device to respond. The exact amount of time it takes for this operation is not critical since the specific Protocol will dictate what to send and how long to wait for the response. This non-deterministic behavior is perfectly acceptable in mission-mode operation but poses major problems for test on ATE. Even for designs using robust Design For Testability (DFT) methodology, non-deterministic behavior can occur during ATE test. One example is Memory Built-In Self Test (MBIST) where the device design incorporates circuitry to test and perhaps repair embedded memory arrays. After initialization and becoming activated, the MBIST controller will operate independently and provide results to ATE once the test is complete. The ATE must recognize when data is available and capture all the failure information provided by the DUT. Depending on the device failure mechanism and desired data (pass/fail, data for bitmapping or redundancy analysis) both the amount of fail data and the time at which that data is made available to the ATE can vary across MBIST engines within a single device. If testing multiple devices in parallel each device response will be different. Existing SOC ATE systems are not architected to deal well with these differences in DUT behavior and must generally capture much more data than actually required just to ensure that no critical information is missed. First silicon bring-up is usually a parallel effort with teams working on bench equipment and ATE. The bench setup usually consists of a PC controlling the DUT through standard debug ports like JTAG and a selection of instruments each dedicated to particular Protocol. It is quite common to get the device running much quicker on the bench than on ATE since communication with bench instruments occurs at a Protocol level. Bench instruments are designed to emulate real-world device operation so they

can deal with the handshaking and non-deterministic device behavior described above. ATE users are not so fortunate. Variations in processing, voltage, or temperature can change the timing of DUT output data and in some cases even the order in which data occurs. This non-determinism can occur not only from device-to-device but from test to test in the same device. There are cases where no pattern will pass 100% of the time on today’s deterministic ATE. It’s not uncommon to run a pattern multiple times and treat the device as good if it passes even once.

2. Dealing with DUT Non-Determinism

2.1 Today’s test compromises In order to deal with unpredictable device behavior during ATE test a few strategies can be employed, some apply to the device design itself and some to the test techniques used. As part of initial design, device operation can be artificially constrained in several ways to help force deterministic behavior. Test structures can be added to the device: - To partition the design for structural test (Scan) - To control clocks for delay fault testing (AC Scan) - To synchronize time domains - So the device can test/repair itself

o Memory Built-In Self Test (MBIST) o Logic Built-In Self Test (LBIST)

To support test on ATE, test strategies can be constrained in several ways to compensate for non-deterministic behavior: - Eliminate problematic tests - Test only one portion of the device at a time - Limit test speed to increase likelihood of deterministic

behavior - Mask (ignore) non-deterministic portions of test

vectors - Run patterns multiple times to increase the likelihood

of detecting a pass

The result of the above constraints in device behavior and test strategies is a relatively well defined and measurable coverage of several classes of faults. Assuming properly constructed test structures and vectors, reasonable fault coverage can be achieved for some fault types including: - Stuck-at, bridging, or open faults - Delay faults that are large enough to be detected with

AC scan - Transition faults Other faults such as those listed below may be fortuitously detected by the techniques described above. There is much ongoing work to create fault models and detection techniques for these types of faults to improve both actual fault coverage and the associated metrics. The current state

of the art is just that, part evolving science and part art. Among the faults that may (or may not) be detected by tests designed to force deterministic behavior are: - Resistive bridging faults and cross-coupling

capacitance faults that cause different effects on path delays with different input patterns

- Delay faults dependent on the global/local activity within the device.

- Transient or soft errors introduced by noise like supply IR-drop, ground bounce, or Ldi/dt

- Leaky gates

2.2 Fault Coverage – DFT versus Mission Mode As seen in table 1 below, at the 2007 VLSI Test Symposium one ASIC manufacturer (IBM) defined reasonable fault coverage. [2]

- 99% stuck-at faults (DC start/DC end) - 85% transition faults (Scan/ASST/TADT)


Table 1 - ASIC Fault Coverage At the same conference a major ASIC customer (Cisco) presented a view of the impact of test, particularly test escapes, on ASIC faults.[3] Almost 70% of the ASIC failures found at system test were attributed to ATE test escapes.

Figure 1 - ASIC Failures at system test

“Topping off” DFT and structural test fault coverage with at-speed functional testing, sometimes referred to as “Mission-Mode” test, is viewed by many semiconductor manufacturers as necessary to achieve the low (sub-100DPM) defect rates required by their customers. Because it is “Hard to emulate (the) functional environment with a standalone chip” Cisco’s current plan includes adding BIST at system level test to help catch and identify failures missed on ATE. Some semiconductor manufacturers have focused on a heavily DFT based test strategy. While still using DFT as a key portion of their test strategy other manufacturers are clearly of the opinion that some form of at-speed functional testing is required to deliver high quality products. At-speed functional test of semiconductor devices can be accomplished at several steps in the manufacturing process. If supported by the device design and behavior can be made predictable, production test on ATE can be expanded to cover at-speed faults. In many other cases a commonly implemented solution is to design active components into the ATE Device Interface Board (DIB). These components can include DRAM’s to help test DDR buses, Flash devices to act as Boot memory, a Field Programmable Gate Array (FPGA) to mimic digital circuitry found in the end application, or TX/RX devices to support handshaking over high speed serial buses. While useful for adding fault coverage to ATE test insertions these active devices add design and manufacturing complexity to the DIB, increasing cost and reducing reliability. In cases where achieving adequate fault coverage cannot be accomplished today on ATE it may be required to temporarily inserting the DUT into a test fixture that emulates the functional environment of the final system application. Often referred to as System Level Test (SLT), this is an additional step in the manufacturing flow and requires separate test and handling equipment. While the SLT equipment is usually less expensive per test cell than SOC ATE systems, throughput and productivity is usually much lower. In addition the SLT is normally very dedicated and is applicable only to a single, high volume device design. Because of the additional cost, both in equipment and test time, use of SLT is generally avoided whenever possible. A third alternative is to wait until the device is in the final application. This is certainly the least desirable and most expensive of the alternatives due to the high cost of replacing the defective component once assembled in the final product, whether a $30 DVD player or a $50K automobile. A strategy of driving at-speed functional test coverage back into ATE would seem to be cost effective relative to waiting until the system is assembled to identify the problems. Without Protocol Aware capability, today’s ATE cannot easily support that strategy.

2.3 Bench versus ATE As mentioned above it’s quite common for new devices to be brought up on both ATE and in a Bench Validation environment. Using PC’s to debug the processor though some host interface such as JTAG, PCI or a dedicated debug bus often has basic functionality working in minutes. In many cases the device comes up much faster on the bench than on ATE since the bench process uses high level language and instruments targeted for specific IP blocks and protocols. Functional coverage can be achieved on the bench in minutes that could take weeks (or forever) on ATE. In the bench environment it’s easy to identify and modify instructions and data sent to the device. Written in high level code, the simulation environment is easily ported to the bench. If the engineer wants to change the contents of a particular internal register it’s a simple matter of creating a transaction that sends a “write” instruction in the chosen protocol. If the contents need to be examined a “read” transaction will return the contents in the proper format. An example of a series (or set) of MDIO transactions appears below courtesy of Broadcom.

Figure 2 – Protocol Transactions from Bench The transactions are human readable and easy to interpret. They can be created and modified quickly with a text editor and immediately applied to the Device Under Test. Once translated to run on ATE all resemblance to the original high level transaction set is lost. It is difficult, if not impossible, to differentiate between instruction and data since all information is contained in ATE pattern files and expressed as a series of vectors containing 10HLMX characters. Picture the difficulty of finding and modifying the data for a specific MDIO write transaction in the ATE pattern below.

Figure 3 – SOC ATE Test pattern

Because of the radically different levels of abstraction between simulation language and ATE test patterns, an operation that takes a one engineer a few seconds on the

bench can involve multiple people and organizations if attempted on ATE. The simple example of modifying a MDIO write instruction can require a very complex edit to the pattern file and likely require a re-simulation. Turn-around time for a re-simulation can be hours because of the number of steps required and the need to move away from the ATE and into the simulation environment.

An additional problem occurs if the test engineer needs assistance from the design or validation community. Design engineers don’t generally deal well with ATE specific pattern languages and test engineers are not particularly conversant at the transaction level. This creates a language barrier that makes debugging difficult.

At one semiconductor manufacturer it’s very common to have the test engineer debugging a problem in ATE terms and the designer sitting right next to them with the simulation information displayed on their laptop. The process of matching ATE results to simulation is very error prone and time consuming. Two widely divergent views of the problem in two separate computing environments is not conducive to efficient problem solving.

Silicon debug can be so difficult that some ATE users have resorted to hooking external instruments to their Device Interface Boards. They use a JTAG Debugger costing less than $3000USD (one example shown below) to solve the problem that their $1,000,000USD SOC Automatic Test Equipment cannot.[4]

BDI1000 High-speed BDM/JTAG Debug Interface

ABATRON AG BDM support for CPU12/16/32/32+, PowerPC, 5xx/8xx, ColdFire JTAG support for ARM, M-CORE, PowerPC 4xx, MIPS32

Figure 4 – JTAG Protocol Debugger Example

A properly implemented Protocol Aware solution will allow the SOC ATE users to create and use transaction level language as easily on ATE as on the bench. One SOC ATE user has specifically identified that adding protocol aware features to next generation testers is critical for maintaining the rapid product development cycle that has brought them success. An initial estimate is that these problems cost them 50-60 days of extra work on each new device. A separate conversation with a major Graphics Processor manufacturer valued every week shaved from silicon bring-up and debug at $10M in the market.

3. Protocol Aware ATE

3.1 Protocol Aware ATE, the history


Protocol Aware ATE is not a new concept, several semiconductor manufacturers have asked for similar c- capability over the last few years. - Micro-Controller Manufacturer 2001 One US-based Micro-Controller manufacturer described non-deterministic device behavior as caused by the combination of high speed packet based protocols and internal asynchronous boundaries. They also noted that simulation can provide deterministic patterns but defect-free silicon may behave differently than simulation. Specifically they asked for a HW/SW solution to analyze data streams at a higher level than bits. A software methodology was developed to capture and post-process DUT output data. While this technique worked well enough to determine whether the device was operating correctly several hundred milliseconds were added to production test times. - Micro-Processor Manufacturer 2001 A major Micro-Processor manufacturer identified a trend toward multiple independent clock-embedded interfaces that would require enhancements to a traditional digital functional test environment that would support non-deterministic timing behavior displayed by these interfaces. They also identified the potential need to synchronize with multiple independent serial ports in a single pattern execution. - High-End SOC manufacturer 2002 In 2002 a high-end SOC manufacturer pointed out that multi-bus devices have out-of-order data even at low frequencies. Simulation predicts one sequence of events but the device may behave differently. They must run the device and see if it works as expected. If not it is necessary to keep moving around the ATE input and output timing until the device works. This is a very time consuming process in an engineering environment and impossible for production test. - Micro-Processor Manufacturer 2003 In 2003 a major Micro-Processor manufacturer described a need for comm-like ATE capability for characterization. The motivation was unique interfaces that had complex handshaking protocols. In order to be stable the protocols required a synchronization handshake since they allowed non-deterministic behavior in the end application.

3.2 Protocol Aware ATE today As previously noted, ATE today generally deals poorly with unpredictable device behavior. There are exceptions, particularly in the High Speed Serial (HSS) area for those protocols using 8b/10b encoded data. Architected in 2003, the 6.4Gbps SB6G from Teradyne can deal with some types of ambiguity coming from the Device Under Test (DUT). Other ATE vendors have also introduced instruments designed to test high speed serial buses. Both the SB6G

and other ATE instruments are capable of Clock Data Recovery (CDR) on High Speed Serial buses. This functionality is critical for dealing with non-deterministic timing from the DUT. [5]

• Clock Recovery and Phase Tracking Per Lane• CDR circuit recovers DUT embeddedclock & centers ATE strobe

• CDR circuit continually tracksData Eye and adjusts strobe

DUT Tx: Non-Deterministic Timing

Jitter / Eye Sample

ProcessingJitter /

Eye Sampler

Compare Vector data

Compare Out-of Order Data

Align Timing &

DataATE Receiver Compare PRBS

Auto-seed

DUT Output

10b boundary

10b boundary

Start

…

CDR Lock Time

10b RAT

Hold-Off

10b Match

…

…

10b boundary

10b boundary

10b boundary

10b boundary

…

Expect Pattern Begins Execution

…

20b Match20b RAT

Hold-Off

CDR 10b Align 20b MatchDisparity & Symbol Map RAM

Receive Align Trigger

…Idle Data1+ Data2-

Data2- Idle Data1+

Data1+ Idle Data2-

Data1+ Data2- Data1- Data2+…

Figure 5 - SB6G & non-deterministic Timing Both the SB6G and other ATE instruments can wait for a specific set of data to be sent from the DUT before comparing for proper output, thus handling the ambiguity associated with exactly when real data appears from the DUT. Additionally the SB6G can selectively ignore data packets such as Idle Cycles that may be injected in the middle of legitimate data streams. [6]

Jitter / Eye Sample

ProcessingJitter /

Eye Sampler

Compare Vector data

Compare Out-of Order Data

Align Timing &

DataATE Receiver Compare PRBS

Auto-seed

Pin Input Symbol

Output Symbol

Send to SigGen

Description

TXA Disparity- Disparity+ Enable Remap all disparity

TXA K28.5- Disable Disable symbol from being sent to SG

TXA K28.5+ Disable Disable symbol from being sent to SG

TXA D31.7+ D31.7- Enable Remap one symbol to another

• Symbol Map and Signature Generator per lane• Symbol Map filters incoming DUT data

• Remaps an incoming 10b symbolto a different 10b symbol (Disparity)

• Prevents an incoming 10b symbolfrom being sent to Sig Gen

• Signature Generator is a set ofLFSR’s that accumulate the filtered data

• Signature Generator outputused to determine pass/fail

DUT Tx: Non-Deterministic Data Order

…Idle Data1+ Data2-

Data2- Idle Data1+

Data1+ Idle Data2-

Data1+ Data2- Data1- Data2+…

Figure 6 - SB6G & non-deterministic Data The SB6G also has the ability to capture the DUT output for later analysis. To better understand what the DUT is actually doing a specially written software tool can show the captured output as either low-level data or in Protocol terms at a higher level of abstraction.


Figure 7 - SB6G Capture Display as 8b/10b Encoded Data

Figure 8 - SB6G Capture Display as PCI Express Symbols While the SB6G does a very good job handling output data from 8B/10B encoded HSS buses like PCI Express and SATA it is unable to react to that data. The SB6G listens well but has no way to recognize and respond to communication from the DUT in real time. One major user of the SB6G gives the SB6G about ¼ credit as a Protocol Aware ATE instrument. A new ATE architecture is required that can behave much more like the DUT’s end application environment.

3.3 Protocol Aware ATE, the future As part of the next round of UltraFLEX digital instruments Teradyne is developing a new ATE architecture– Protocol Aware ATE. It’s a very ambitious project that will require new software, hardware, and firmware. The intelligence required to handle protocols is contained in a FPGA on the ATE Pin Electronics instrument that can be re-programmed based on the particular protocols required by any individual device program. The list of potential protocols to support is endless and clearly they cannot be supported at once. Some are so low volume that it may not be worth the effort. Others may be too complex to implement in a practical manner. The hardware and software implementation of PA must be flexible enough to provide a solution for many different protocols. Some of these protocols have similar characteristics and can be thought of as a Protocol Family. The table below is a partial list of popular protocols and potential groupings.


Low Speed Serial and Parallel

• JTAG • MDIO • SRAM • Flash

DRAM

• DDR, DDR2, DDR3 • LPDDR, LPDDR2 • GDDR3, GDDR4, GDDR5

High Speed Serial

• PCI Express • SATA • DigRF • Serial RapidIO

3.4 Protocol Aware ATE Implementation As previously noted limited solutions exist today to deal with non-deterministic device behavior and some level of Protocol interaction. These solutions generally add cost to the engineering and manufacturing process through added design complexity, additional production test time, or the need for dedicated system level test cells. While Protocol Aware ATE requires a new architecture and cannot be simply dropped into to existing instruments it does offer the potential to increase the quality and reduce the cost of test for complex SOC devices.

As mentioned above one possible architecture involves the addition of a FPGA to standard ATE Digital Instruments. The purpose of the FPGA is to emulate operation of selected DUT protocols. This requires that the ATE software and hardware support re-programming of the FPGA to act properly depending on the protocol required. Some protocols, JTAG for example, are slow speed and serial in nature and require only a few connections to the device. Others such as DDR2 and DDR3 are much higher speed and parallel in nature requiring dozens of ATE channels to work closely together to interpret and respond to command and data information from the DUT. This “Protocol Engine” architecture allows handshaking between the DUT and the ATE instrument with the ATE interpreting instructions from the selected Protocol and responding accordingly. Response time will naturally be determined by the latency between the DUT launching information to the ATE, the ATE instrument interpreting the information and sending the response to the DUT. Keeping this latency as short as possible is a key design parameter for any Protocol Aware instrument.

DSSCLogic

PatgenTTTiming

Pin Electronics

PE

Select between normal PE operation and Protocol Engine

HostComputer

Protocol Aware Channels

FPGA Based

DUT

DSSCLogic

PatgenTTTiming

Pin Electronics

PE

Select between normal PE operation and Protocol Engine

HostComputer

Protocol Aware Channels

FPGA Based

DUT

Fig 9 – Protocol Aware Digital Instrument Architecture

In addition to emulating the desired Protocol, the instrument must also support classic Digital ATE test functionality such as Scan, DFT, functional test, and characterization. The user must be able to select between “normal” and Protocol Aware operation during both engineering and production test.

One key requirement for solving the “Bench versus ATE” problem introduced in section 2.3 is the ability to read and write internal DUT registers in a simple and straightforward manner, similar to the high level language used in simulation and bench instruments. A properly implemented Protocol Aware solution will allow the user to enter a read or write command along with the associated address and payload data and have the DUT immediately respond.


Re-creating sets of transactions from simulation or bench instrument on ATE will no longer require translation to the low level language of ATE patterns.

Instead of appearing as a pseudo-random group of 1’s and 0’s the DUT interaction will be at a high level of abstraction. One possible syntax is shown below.

Fig 10 – Protocol Aware Digital Instrument Architecture

Dealing with the DUT with a higher level language, similar to the design environment will speed debug and reduce time-to-market of new SOC devices.

3.5 What problems can Protocol Aware ATE Potentially Address? TIME TO MARKET

- Faster bringup of early silicon - Faster debug of customer returns - Faster correlation to bench instruments - Faster pattern generation, DUT native

language - Faster pattern debug, DUT native language - Real-time pattern debug, immediate mode

QUALITY

- Better fault coverage thru Mission-Mode functional testing

PRODUCTION ECONOMICS (Test Time)

- Reduce/eliminate the need to capture and post-process DUT output data

- Eliminate re-running the pattern multiple times to find a pass

- Fewer re-tests

- Reduce/eliminate system level test requirements

DIB COMPLEXITY/COST/RELIABILITY

- Reduce/eliminate “Golden Device” - Reduce/eliminate FLASH, DRAM, SERDES

devices on the DIB, particularly critical for multi-site test

Fig 11 – Protocol Aaware User Benefits [7]

4. Limitations Limitations come with every project and Protocol Aware ATE is no exception. The most obvious issue is the huge and growing number of protocols. It is clear that not all protocols are created equal, either in ease of implementation or popularity. Initial solutions will cover a set of popular protocols with an expanded list available over time.

The speed of ATE PA engines is limited by a couple of bus characteristics and ATE attributes. If the bus requires I/O handshaking the round-trip delay of the pin electronics along with processing time in the FPGA may limit speed to that of low speed protocols. Buses that do not require handshaking can generally be supported up to much higher speeds, limited by the fundamental operating frequency of the FPGA.

5. Discussion As detailed in section 3.5 above there are a number of areas where Protocol Aware ATE can provide benefits to ATE users. As with most new concepts the actual benefits will become more obvious over time. Since PA ATE is still in it’s infancy we can really only speculate as to the long term value to ATE users but a few things seem obvious.

- Broadcom has determined that Protocol Aware capability is the next architectural breakthrough in ATE and they are pushing both their suppliers and competitors to get on board.

Protocol(MyMDIO).Send(mdio_frame_write, &01, &1f, &00F0)‘ MDIO block address Rx0Protocol(MyMDIO).Recieve(mdio_frame_read_rang_compare, &01, anaRXStatus_A, &8000,&0000)` Read PRBS Error CountProtocol(MyMDIO).Send(mdio_frame_write, &01, &1f, &0100)‘ MDIO block address Rx1Protocol(MyMDIO).Recieve(mdio_frame_read_rang_compare, &01, anaRXStatus_A, &8000,&0000)` Read PRBS Error CountProtocol(MyMDIO).Send(mdio_frame_write, &01, &1f, &00F0)‘ MDIO block address Rx2Protocol(MyMDIO).Recieve(mdio_frame_read_rang_compare, &01, anaRXStatus_A, &8000,&0000)` Read PRBS Error CountProtocol(MyMDIO).Send(mdio_frame_write, &01, &1f, &0100)‘ MDIO block address Rx3Protocol(MyMDIO).Recieve(mdio_frame_read_rang_compare, &01, anaRXStatus_A, &8000,&0000)` Read PRBS Error Count

ImproveFault

CoverageAnd DPM

ImproveEarly

SiliconYield

Speed UpSiliconDebug

ReduceCustomer

Returnebug TimeD

ProtocolAwareATE

Time toMarket

ProductionEconomicsQuality

ReduceTest Time

Reduce PgmDevelop &

Debug Time

Reduce orEliminateSystem

Level Test

Reduce DIBComplexity

ImproveFault

CoverageAnd DPM

ImproveFault

CoverageAnd DPM

ImproveEarly

SiliconYield

ImproveEarly

SiliconYield



ReduceustomerReturn

ebug Time

C

D

ReduceustomerReturn

ebug Time

C

D

ProtocolAwareATE

Time toMarket

ProductionEconomicsQuality

ReduceTest Time

Reduce PgmDevelop &

Debug Time

Reduce PgmDevelop &

Debug Time

ReduceTest Time


Level Test


Level Test

Reduce DIBComplexityReduce DIBComplexity


- Other Semiconductor Manufacturers are very interested in the concept

- Teradyne believes that Protocol Aware ATE has tremendous value and is actively developing solutions.

- The concept is very compelling to many semiconductor manufacturers because of the Time-To-Market issues that PA ATE can help address

Maybe not so obvious is the possibility of overstating Protocol Aware ATE as a general solution. Many ATE users have expressed interest in PA ATE as a replacement for their current System Level Test (SLT) strategy. While PA ATE can certainly supplement and substitute for some level of SLT it is doubtful that it will ever be a complete solution. Latency limitations described above will limit PA ATE as a drop-in replacement for high speed DRAM on a DIB. It is also clear that Protocol Aware ATE is complementary to existing test techniques and DFT/Structural test is still a necessary component of the overall test strategy.

Conclusion: Protocol Aware ATE is a new architecture and all indications are that as a concept it is very appealing to a broad set of ATE users, both existing and potential. Implemented properly PA ATE can provide immediate payback by improving test development time and reducing customer Time-To-Market. In the long run additional benefits around better fault coverage will also become apparent.

This concept signals a fundamental shift in SOC ATE architecture. Future digital instruments will be designed to be Protocol Aware. While starting with digital, PA

capability applies to analog and mixed signal instruments as well.

References: [1] Andy Evans, Vision ATE 2020 at ITC 2007 [2] Vikram Iyengar et al, “An Integrated Framework for

At-speed and ATE-Driven Delay Test of Contract Manufactured ASICs”, Proceedings VLSI Test Symposium, 2007, Session 4B Paper 2

[3] Zoe Conroy, Bill Eklow, VLSI Test Symposium 2007, Innovative Practices

[4] Abatron AG Website [5] Eric Larson, VLSI Test Symposium 2007, Innovative

Practices [6] Eric Larson, VLSI Test Symposium 2007, Innovative

Practices [7] Eric Larson, Kyoichi Sei, Teradyne User Group

Japan, November 2007 Acknowledgments: Many colleagues have contributed to the pool of knowledge and opinion reflected in this document. In particular I would like to recognize the teams that have been working closely with our lead customers for several months now to ensure we develop a product that fits the market need.

- Teradyne’s Protocol Aware Hardware/Software/FPGA Design Team - The Teradyne UltraFLEX Digital Tools Project Team - Highly skilled ATE users at lead customers