2008 Asts Technical Paper Protocol Aware Ate Submitted

Protocol Aware ATE
Eric Larson
Teradyne
30701 Agoura Road
Agoura Hills, Calif USA 91301

Biography 1. Introduction
Eric Larson has more than 28 years of experience
SOC device operation is often non-deterministic in the end
working at Teradyne in roles ranging from Factory
application (mission mode). Devices seamlessly
Applications Engineer to Field Product Specialist, and
communicate and handshake to establish operating
Technical Marketing. Eric has been involved with
parameters such as data timing and operating frequency.
supporting Teradyne’s Logic and SOC test systems
This capability, while perfectly acceptable and necessary in
from J283 through Catalyst and UltraFLEX. He
the customer application can cause serious problems during
currently works in the Broadband, Computing, and
ATE test. Among the reasons for non-deterministic
Storage (BCS) Business Unit focusing on Digital
behavior in a test environment are:
testing, both high speed and DFT.

- Multiple time domains with no frequency relationship
Abstract:
- Asynchronously linked buses with an independent PLL
Modern semiconductor devices often behave in a non-
per time domain
deterministic manner not only in their end application but
- I/O buses using many different complex protocols and
during test execution on ATE as well. This is the result of
clocking schemes
design methodologies that allow the assembly of the device
- Different behavior across Process, Voltage, and
from a library of IP blocks. These IP blocks often support
Temperature (PVT) including shifts in timing, insertion
specific industry standard protocols such as JTAG, DDR
of idle cycles, and changes in data order
memory buses, PCI Express, etc. While the operation of any
individual block may be predictable the timing relationship
Current stored response ATE architectures can only deal
between protocols often is not. Today’s SOC ATE does not
with deterministic behavior during test. As a result
deal well with ambiguity. Any deviation from expected
device behavior will cause that device to fail ATE test, both
- Test development time is long because of the
during engineering development or production.
difference in Device Under Test (DUT) behavior in
Functionally testing devices that exhibit non-deterministic
design and ATE
behavior is extremely difficult on current generation ATE.
- Fault coverage is inadequate because the DUT is not
This paper describes a proposed solution to deal with non- tested in “Mission Mode” (end application)
deterministic device behavior, a new ATE architecture - - Test times are long because multiple pattern
Protocol Aware ATE (PA-ATE). Specifically covered will executions are required looking for a pass or the DUT
be some of the problems currently faced by Semiconductor output must be captured and post-processed
ATE users and the usefulness of Protocol Aware ATE to - Early silicon yield is reduced because good devices
address those problems. don’t match ATE pass conditions
As described by Andy Evans of Broadcom, protocol Aware
This problem is becoming more pervasive. The
ATE is an:
semiconductor design community has a rich set of
“ATE Architecture which can natively emulate real time proprietary and commercial tools available to simplify and
chip I/O at the Protocol Level. speed up device design.
Enables testing a device [with methods] ranging from using
- Design teams develop full feature designs faster using
a single chip interface to total “Mission Mode”, at the
Asynchronous IP that speeds design time and chip
highest level of abstraction centric to the interfaces specific
timing closure
protocols.” [1]
- 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 can deal with the handshaking and non-deterministic device
converted to vectors (time based). Test engineers must behavior described above.
debug with low level vectors - ’01HLX’.
- Asynchronous Interfaces cause non-determinism, ATE users are not so fortunate. Variations in processing,
which test engineers must try to predict and adjust for voltage, or temperature can change the timing of DUT
in the timing and vectors (may shift with Process output data and in some cases even the order in which data
Variation). occurs. This non-determinism can occur not only from
device-to-device but from test to test in the same device.
The device design methodology and behavior described There are cases where no pattern will pass 100% of the time
above causes a number of problems for the test community. on today’s deterministic ATE. It’s not uncommon to run a
pattern multiple times and treat the device as good if it
When operating in the end application (mission mode) passes even once.
many devices require some sort of interaction to:
2. Dealing with DUT Non-Determinism
- Establish communication parameters such as bus speed
and width.
2.1 Today’s test compromises
- Set up internal register states for proper operation
In order to deal with unpredictable device behavior during
- Load up internal memory (SRAM, DRAM or Flash)
ATE test a few strategies can be employed, some apply to
with information required for the device to properly
the device design itself and some to the test techniques used.
operate, sometimes referred to as boot code

As part of initial design, device operation can be artificially
This device-to-device interaction often involves two-way
constrained in several ways to help force deterministic
handshaking. One device will send information and wait
behavior. Test structures can be added to the device:
for the other device to respond. The exact amount of time it
takes for this operation is not critical since the specific
- To partition the design for structural test (Scan)
Protocol will dictate what to send and how long to wait for
- To control clocks for delay fault testing (AC Scan)
the response. This non-deterministic behavior is perfectly
- To synchronize time domains
acceptable in mission-mode operation but poses major
- So the device can test/repair itself
problems for test on ATE.
o Memory Built-In Self Test (MBIST)
o Logic Built-In Self Test (LBIST)
Even for designs using robust Design For Testability (DFT)
methodology, non-deterministic behavior can occur during
To support test on ATE, test strategies can be constrained in
ATE test. One example is Memory Built-In Self Test
several ways to compensate for non-deterministic behavior:
(MBIST) where the device design incorporates circuitry to
test and perhaps repair embedded memory arrays. After
- Eliminate problematic tests
initialization and becoming activated, the MBIST controller
- Test only one portion of the device at a time
will operate independently and provide results to ATE once
- Limit test speed to increase likelihood of deterministic
the test is complete. The ATE must recognize when data is
behavior
available and capture all the failure information provided by
- Mask (ignore) non-deterministic portions of test
the DUT. Depending on the device failure mechanism and
vectors
desired data (pass/fail, data for bitmapping or redundancy
- Run patterns multiple times to increase the likelihood
analysis) both the amount of fail data and the time at which
of detecting a pass
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. The result of the above constraints in device behavior and
Existing SOC ATE systems are not architected to deal well test strategies is a relatively well defined and measurable
with these differences in DUT behavior and must generally coverage of several classes of faults. Assuming properly
capture much more data than actually required just to constructed test structures and vectors, reasonable fault
ensure that no critical information is missed. coverage can be achieved for some fault types including:
First silicon bring-up is usually a parallel effort with teams - Stuck-at, bridging, or open faults
working on bench equipment and ATE. The bench setup - Delay faults that are large enough to be detected with
usually consists of a PC controlling the DUT through AC scan
standard debug ports like JTAG and a selection of - Transition faults
instruments each dedicated to particular Protocol. It is quite
common to get the device running much quicker on the Other faults such as those listed below may be fortuitously
bench than on ATE since communication with bench detected by the techniques described above. There is much
instruments occurs at a Protocol level. Bench instruments ongoing work to create fault models and detection
are designed to emulate real-world device operation so they 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. “Topping off” DFT and structural test fault coverage with
Among the faults that may (or may not) be detected by tests at-speed functional testing, sometimes referred to as
designed to force deterministic behavior are: “Mission-Mode” test, is viewed by many semiconductor
manufacturers as necessary to achieve the low (sub-
- Resistive bridging faults and cross-coupling 100DPM) defect rates required by their customers. Because
capacitance faults that cause different effects on path it is “Hard to emulate (the) functional environment with a
delays with different input patterns standalone chip” Cisco’s current plan includes adding BIST
- Delay faults dependent on the global/local activity at system level test to help catch and identify failures
within the device. missed on ATE.
- Transient or soft errors introduced by noise like supply
IR-drop, ground bounce, or Ldi/dt Some semiconductor manufacturers have focused on a
- Leaky gates 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
2.2 Fault Coverage – DFT versus Mission Mode
testing is required to deliver high quality products.
As seen in table 1 below, at the 2007 VLSI Test
Symposium one ASIC manufacturer (IBM) defined At-speed functional test of semiconductor devices can be
reasonable fault coverage. [2] accomplished at several steps in the manufacturing process.
- 99% stuck-at faults (DC start/DC end) If supported by the device design and behavior can be made
- 85% transition faults (Scan/ASST/TADT) 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
Table 1 - ASIC Fault Coverage
temporarily inserting the DUT into a test fixture that
emulates the functional environment of the final system
At the same conference a major ASIC customer (Cisco)
application. Often referred to as System Level Test (SLT),
presented a view of the impact of test, particularly test
this is an additional step in the manufacturing flow and
escapes, on ASIC faults.[3] Almost 70% of the ASIC
requires separate test and handling equipment. While the
failures found at system test were attributed to ATE test
SLT equipment is usually less expensive per test cell than
escapes.
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.
Figure 1 - ASIC Failures at system test Without Protocol Aware capability, today’s ATE cannot
easily support that strategy.

bench can involve multiple people and organizations if
2.3 Bench versus ATE
attempted on ATE. The simple example of modifying a
As mentioned above it’s quite common for new devices to
MDIO write instruction can require a very complex edit to
be brought up on both ATE and in a Bench Validation
the pattern file and likely require a re-simulation. Turn-
environment. Using PC’s to debug the processor though
around time for a re-simulation can be hours because of the
some host interface such as JTAG, PCI or a dedicated
number of steps required and the need to move away from
debug bus often has basic functionality working in minutes.
the ATE and into the simulation environment.
In many cases the device comes up much faster on the
bench than on ATE since the bench process uses high level
An additional problem occurs if the test engineer needs
language and instruments targeted for specific IP blocks and
assistance from the design or validation community.
protocols. Functional coverage can be achieved on the
Design engineers don’t generally deal well with ATE
bench in minutes that could take weeks (or forever) on ATE.
specific pattern languages and test engineers are not
particularly conversant at the transaction level. This creates
In the bench environment it’s easy to identify and modify
a language barrier that makes debugging difficult.
instructions and data sent to the device. Written in high
level code, the simulation environment is easily ported to At one semiconductor manufacturer it’s very common to
the bench. If the engineer wants to change the contents of a have the test engineer debugging a problem in ATE terms
particular internal register it’s a simple matter of creating a and the designer sitting right next to them with the
transaction that sends a “write” instruction in the chosen simulation information displayed on their laptop. The
protocol. If the contents need to be examined a “read” process of matching ATE results to simulation is very error
transaction will return the contents in the proper format. An prone and time consuming. Two widely divergent views of
example of a series (or set) of MDIO transactions appears the problem in two separate computing environments is not
below courtesy of Broadcom. 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]
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
BDI1000 High-speed BDM/JTAG Debug Interface
not impossible, to differentiate between instruction and data
since all information is contained in ATE pattern files and ABATRON AG
expressed as a series of vectors containing 10HLMX
BDM support for CPU12/16/32/32+, PowerPC, 5xx/8xx, ColdFire
characters. Picture the difficulty of finding and modifying
the data for a specific MDIO write transaction in the ATE JTAG support for ARM, M-CORE, PowerPC 4xx, MIPS32
pattern below.
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.
Figure 3 – SOC ATE Test pattern
Because of the radically different levels of abstraction 3. Protocol Aware ATE
between simulation language and ATE test patterns, an
operation that takes a one engineer a few seconds on the 3.1 Protocol Aware ATE, the history

and other ATE instruments are capable of Clock Data
Protocol Aware ATE is not a new concept, several Recovery (CDR) on High Speed Serial buses. This
semiconductor manufacturers have asked for similar c- functionality is critical for dealing with non-deterministic
capability over the last few years. timing from the DUT. [5]

- Micro-Controller Manufacturer 2001 DUT Tx: Non-Deterministic Timing
One US-based Micro-Controller manufacturer described
• Clock Recovery and Phase Tracking Per Lane
non-deterministic device behavior as caused by the
• CDR circuit recovers DUT embedded
combination of high speed packet based protocols and Jitter / Eye
Jitter / Sample
clock & centers ATE strobe
internal asynchronous boundaries. They also noted that Eye Processing
Sampler
Compare

• CDR circuit continually tracks
simulation can provide deterministic patterns but defect-free Vector data
Align
Timing &
Data Compare PRBS

Data Eye and adjusts strobe ATE Receiver
silicon may behave differently than simulation. Specifically Auto-seed

Compare Out-
they asked for a HW/SW solution to analyze data streams at of Order Data

a higher level than bits. A software methodology was Receive Align Trigger

developed to capture and post-process DUT output data. Disparity
CDR 10b Align 20b Match
& Symbol
Map RAM

…
While this technique worked well enough to determine Idle Data1+ Data2-

…
whether the device was operating correctly several hundred Data1+ Data2- Data1- Data2+
10b 10b 10b 10b 10b
10b

milliseconds were added to production test times. boundary boundary boundary boundary boundary
boundary
Data1+ Idle Data2-
…
DUT Output … …

…
…
Data2- Idle Data1+
Start
20b 20b Match
CDR Lock 10b 10b Match

- Micro-Processor Manufacturer 2001 RAT
Time RAT
Expect Pattern Begins Execution
Hold-Off
Hold-Off

A major Micro-Processor manufacturer identified a trend Figure 5 - SB6G & non-deterministic Timing
toward multiple independent clock-embedded interfaces
that would require enhancements to a traditional digital Both the SB6G and other ATE instruments can wait for a
functional test environment that would support non- specific set of data to be sent from the DUT before
deterministic timing behavior displayed by these interfaces. comparing for proper output, thus handling the ambiguity
They also identified the potential need to synchronize with associated with exactly when real data appears from the
multiple independent serial ports in a single pattern DUT. Additionally the SB6G can selectively ignore data
execution. packets such as Idle Cycles that may be injected in the
middle of legitimate data streams. [6]
- 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
DUT Tx: Non-Deterministic Data Order
frequencies. Simulation predicts one sequence of events
• Symbol Map and Signature Generator per lane
but the device may behave differently. They must run the
• Symbol Map filters incoming DUT data
device and see if it works as expected. If not it is necessary
• Remaps an incoming 10b symbol
to keep moving around the ATE input and output timing to a different 10b symbol (Disparity) Jitter / Eye
Jitter / Sample

until the device works. This is a very time consuming Eye Processing
• Prevents an incoming 10b symbol Sampler
Compare

process in an engineering environment and impossible for Vector data
from being sent to Sig Gen Align
Timing &
Data Compare PRBS
• Signature Generator is a set of ATE Receiver
production test. Auto-seed

LFSR’s that accumulate the filtered data Compare Out-
of Order Data

• Signature Generator output
- Micro-Processor Manufacturer 2003 Pin Input Output Send to Description

used to determine pass/fail Symbol Symbol SigGen
In 2003 a major Micro-Processor manufacturer described a TXA Disparity- Disparity+ Enable Remap all disparity

…
need for comm-like ATE capability for characterization. Idle Data1+ Data2-
TXA K28.5- Disable Disable symbol from being sent to SG

…
The motivation was unique interfaces that had complex Data1+ Data2- Data1- Data2+
TXA K28.5+ Disable Disable symbol from being sent to SG

handshaking protocols. In order to be stable the protocols Data1+ Idle Data2-
TXA D31.7+ D31.7- Enable Remap one symbol to another

required a synchronization handshake since they allowed Data2- Idle Data1+

non-deterministic behavior in the end application.
Figure 6 - SB6G & non-deterministic Data

The SB6G also has the ability to capture the DUT output
3.2 Protocol Aware ATE today for later analysis. To better understand what the DUT is
actually doing a specially written software tool can show
As previously noted, ATE today generally deals poorly with
the captured output as either low-level data or in Protocol
unpredictable device behavior. There are exceptions,
terms at a higher level of abstraction.
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


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

High Speed Serial
• PCI Express
Figure 7 - SB6G Capture Display as 8b/10b Encoded Data • 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
Figure 8 - SB6G Capture Display as PCI Express Symbols
the engineering and manufacturing process through added
design complexity, additional production test time, or the
While the SB6G does a very good job handling output data
need for dedicated system level test cells. While Protocol
from 8B/10B encoded HSS buses like PCI Express and
Aware ATE requires a new architecture and cannot be
SATA it is unable to react to that data. The SB6G listens
simply dropped into to existing instruments it does offer the
well but has no way to recognize and respond to
potential to increase the quality and reduce the cost of test
communication from the DUT in real time.
for complex SOC devices.
One major user of the SB6G gives the SB6G about ¼ credit As mentioned above one possible architecture involves the
as a Protocol Aware ATE instrument. A new ATE addition of a FPGA to standard ATE Digital Instruments.
architecture is required that can behave much more like the The purpose of the FPGA is to emulate operation of
DUT’s end application environment. 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.
3.3 Protocol Aware ATE, the future
Some protocols, JTAG for example, are slow speed and
As part of the next round of UltraFLEX digital instruments
serial in nature and require only a few connections to the
Teradyne is developing a new ATE architecture– Protocol
device. Others such as DDR2 and DDR3 are much higher
Aware ATE.
speed and parallel in nature requiring dozens of ATE
channels to work closely together to interpret and respond
It’s a very ambitious project that will require new software,
to command and data information from the DUT. This
hardware, and firmware. The intelligence required to
“Protocol Engine” architecture allows handshaking between
handle protocols is contained in a FPGA on the ATE Pin
the DUT and the ATE instrument with the ATE interpreting
Electronics instrument that can be re-programmed based on
instructions from the selected Protocol and responding
the particular protocols required by any individual device
accordingly. Response time will naturally be determined
program.
by the latency between the DUT launching information to
the ATE, the ATE instrument interpreting the information
The list of potential protocols to support is endless and
and sending the response to the DUT. Keeping this latency
clearly they cannot be supported at once. Some are so low
as short as possible is a key design parameter for any
volume that it may not be worth the effort. Others may be
Protocol Aware instrument.
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 DSSC Pin Electronics
characteristics and can be thought of as a Protocol Family. Host T
Logic
T
Computer DUT
PE
Patgen Timing
The table below is a partial list of popular protocols and
potential groupings.
Protocol Aware
Channels Select between normal PE
FPGA Based
Low Speed Serial and Parallel operation and Protocol Engine
• JTAG
• MDIO Fig 9 – Protocol Aware Digital Instrument Architecture
• SRAM
• Flash

-
In addition to emulating the desired Protocol, the Reduce/eliminate system level test
instrument must also support classic Digital ATE test requirements
functionality such as Scan, DFT, functional test, and
characterization. The user must be able to select between DIB COMPLEXITY/COST/RELIABILITY
- Reduce/eliminate “Golden Device”
“normal” and Protocol Aware operation during both
- Reduce/eliminate FLASH, DRAM, SERDES
engineering and production test.
devices on the DIB, particularly critical for
One key requirement for solving the “Bench versus ATE” multi-site test
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 Improve
Reduce Pgm
Early
Develop &
Protocol Aware solution will allow the user to enter a read Silicon
Debug Time
Yield
or write command along with the associated address and Speed Up
Reduce
Silicon
payload data and have the DUT immediately respond. Test Time
Debug
Protocol
Aware
Re-creating sets of transactions from simulation or bench ATE
Reduce Reduce or
instrument on ATE will no longer require translation to the Customer
Customer Eliminate
Return System
low level language of ATE patterns. Debug Time Level Test

Improve
Fault Reduce DIB
Instead of appearing as a pseudo-random group of 1’s and Coverage Complexity
And DPM
0’s the DUT interaction will be at a high level of
abstraction. One possible syntax is shown below.
Time to Production
Quality
Protocol(MyMDIO).Send(mdio_frame_write, &01, &1f, &00F0)‘ MDIO block address Rx0 Market Economics
Protocol(MyMDIO).Recieve(mdio_frame_read_rang_compare, &01, anaRXStatus_A, &8000,&0000)` Read PRBS Error Count
Protocol(MyMDIO).Send(mdio_frame_write, &01, &1f, &0100)‘ MDIO block address Rx1
Protocol(MyMDIO).Send(mdio_frame_write, &01, &1f, &00F0)‘ MDIO block address Rx2
Fig 11 – Protocol Aaware User Benefits [7]
Protocol(MyMDIO).Send(mdio_frame_write, &01, &1f, &0100)‘ MDIO block address Rx3

4. Limitations
Fig 10 – Protocol Aware Digital Instrument Architecture
Limitations come with every project and Protocol Aware
ATE is no exception. The most obvious issue is the huge
Dealing with the DUT with a higher level language, similar
and growing number of protocols. It is clear that not all
to the design environment will speed debug and reduce
protocols are created equal, either in ease of
time-to-market of new SOC devices.
implementation or popularity. Initial solutions will cover a
set of popular protocols with an expanded list available
over time.
3.5 What problems can Protocol Aware ATE
The speed of ATE PA engines is limited by a couple of bus
Potentially Address?
characteristics and ATE attributes. If the bus requires I/O
handshaking the round-trip delay of the pin electronics
TIME TO MARKET
along with processing time in the FPGA may limit speed to
- Faster bringup of early silicon
that of low speed protocols. Buses that do not require
- Faster debug of customer returns
handshaking can generally be supported up to much higher
- Faster correlation to bench instruments
speeds, limited by the fundamental operating frequency of
- Faster pattern generation, DUT native
the FPGA.
language
- Faster pattern debug, DUT native language
5. Discussion
- Real-time pattern debug, immediate mode
As detailed in section 3.5 above there are a number of areas
QUALITY where Protocol Aware ATE can provide benefits to ATE
- Better fault coverage thru Mission-Mode users. As with most new concepts the actual benefits will
become more obvious over time. Since PA ATE is still in
functional testing
it’s infancy we can really only speculate as to the long term
value to ATE users but a few things seem obvious.
PRODUCTION ECONOMICS (Test Time)
- Reduce/eliminate the need to capture and post-
- Broadcom has determined that Protocol Aware
process DUT output data
capability is the next architectural breakthrough in
- Eliminate re-running the pattern multiple
ATE and they are pushing both their suppliers and
times to find a pass
competitors to get on board.
- Fewer re-tests


- Other Semiconductor Manufacturers are very capability applies to analog and mixed signal instruments as
interested in the concept well.
- Teradyne believes that Protocol Aware ATE has
tremendous value and is actively developing References:
solutions. [1] Andy Evans, Vision ATE 2020 at ITC 2007
[2] Vikram Iyengar et al, “An Integrated Framework for
- The concept is very compelling to many
At-speed and ATE-Driven Delay Test of Contract
semiconductor manufacturers because of the
Manufactured ASICs”, Proceedings VLSI Test
Time-To-Market issues that PA ATE can help
Symposium, 2007, Session 4B Paper 2
address
[3] Zoe Conroy, Bill Eklow, VLSI Test Symposium 2007,
Maybe not so obvious is the possibility of overstating Innovative Practices
Protocol Aware ATE as a general solution. Many ATE [4] Abatron AG Website
users have expressed interest in PA ATE as a replacement [5] Eric Larson, VLSI Test Symposium 2007, Innovative
for their current System Level Test (SLT) strategy. While Practices
PA ATE can certainly supplement and substitute for some [6] Eric Larson, VLSI Test Symposium 2007, Innovative
level of SLT it is doubtful that it will ever be a complete Practices
solution. Latency limitations described above will limit PA [7] Eric Larson, Kyoichi Sei, Teradyne User Group
ATE as a drop-in replacement for high speed DRAM on a Japan, November 2007
DIB. It is also clear that Protocol Aware ATE is
complementary to existing test techniques and Acknowledgments:
DFT/Structural test is still a necessary component of the Many colleagues have contributed to the pool of knowledge
overall test strategy. and opinion reflected in this document. In particular I
would like to recognize the teams that have been working
Conclusion:
closely with our lead customers for several months now to
Protocol Aware ATE is a new architecture and all
ensure we develop a product that fits the market need.
indications are that as a concept it is very appealing to a
broad set of ATE users, both existing and potential. - Teradyne’s Protocol Aware Hardware/Software/FPGA
Implemented properly PA ATE can provide immediate Design Team
payback by improving test development time and reducing - The Teradyne UltraFLEX Digital Tools Project Team
customer Time-To-Market. In the long run additional - Highly skilled ATE users at lead customers
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


2008 Asts Technical Paper Protocol Aware Ate Submitted

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to 2008 Asts Technical Paper Protocol Aware Ate Submitted

Similar to 2008 Asts Technical Paper Protocol Aware Ate Submitted (20)

Recently uploaded

Recently uploaded (20)

2008 Asts Technical Paper Protocol Aware Ate Submitted