protocol aware ate semi submitted

2009-3-3

2008 Beijing Advanced Semiconductor Technology Symposium1

Protocol Aware ATE

Eric LarsonSenior Product Specialist

2009-3-3 2008 Beijing Advanced Semiconductor Technology Symposium2

A SMARTER TESTER MAKES TESTING EASIER

• In the end application semiconductor devices communicate with each other at a high level of abstraction (Protocols), sending information back and forth much like people having a phone conversation.

• Device designers use these Protocols to create and validate their designs• ATE today does not "speak" Protocols so ATE users must interact with

Devices Under Test at a very low level of abstraction (Vectors), very much like communicating in ASCII Code.

• Making ATE "Protocol Aware" will allow ATE users to interact with the device using the same Protocol level of abstraction as designers

• Smarter ATE will make it much easier to interact with the devices during silicon bring-up and debug on ATE and feed back results to design. Faster debug means reduced development cycles and faster Time-to-Market

Why Protocol Aware Automatic Test Equipment (ATE)?


• The Impact of Silicon Integration on ATE Users

• Protocol Aware ATE Applications– Reduce or Eliminate System Level Test– Speed up Silicon Bring-up and Debug

• Protocol Aware ATE Architecture

Protocol Aware ATE: Outline


Impact of Silicon Integrationon Device and ATE Complexity

In each decade semiconductor device complexity increases by >10x and requires a new tester architecture

Time

Chip Complexity(Transistor Count)

10,000

100,000

1,000,000

10,000,000

100,000,000

1,000,000,000

10,000,000,000

Transistor Count

Test

Comple

xity

- New complex devices have more IP Blocks, more gates, more clock domains. - IP re-use makes devices easier and faster to

design but more difficult and slower to test.

1990’sLogic, Memory & Analog

Analog non-determinism

1980’sMultiple Digital functions

Complex Timing

2010’sIP re-use & DUT Master

Digital non-determinism

Per Pin Timing

Mixed Signal & Memory Test

Protocol Aware

2000’s

Integrated RFAnd SERDES

RF & SERDESHigh speeds


- Re-usable design IP allows designers to:- Tape out full feature designs faster using Asynchronous IP thatspeeds design time and chip timing closure

- Work with high level behavioral simulations, simplifying verification of complex bus protocols

IP re-use:Design Engineer Heaven

533 -1600 Mbps

5000 MbpsCPUCoreIP x 2

Bus InterfaceIP

PCIExpress IP

SATA IP DRAMSRAM

Cache IP

USB2.0IP

800 Mbps

480 Mbps

533 -1600 Mbps3000 Mbps

PLLPLL

PLL

PLL

PLL

DD

RC

ontr

olle

r IP

DD

RC

ontr

olle

r IP

PLL

SDIO IPJTAG IPSPI IP

LowSpeed


- Test Engineers do not have re-usable TEST IP- Protocol 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 vectors (mayshift with Process Variation)

IP re-use:Test Engineer Hell

6

533 -1600 Mbps

5000 MbpsCPUCoreIP x 2

Bus InterfaceIP

PCIExpress IP

SATA IP DRAMSRAM

Cache IP

USB2.0IP

800 Mbps

480 Mbps

533 -1600 Mbps3000 Mbps

PLLPLL

PLL

PLL

PLL

DD

RC

ontr

olle

r IP

DD

RC

ontr

olle

r IP

PLL


LowSpeed


DUT and Tester Misalignment

• I/O buses use many different complex protocols and clocking schemes

• Multiple clock domains with no frequency relationship

• Asynchronously linked buses have independent PLLs per clock domain

• Behavior changes across Process, Voltage, and Temperature (PVT) including shifts in timing, insertion of idle cycles, changes in data order.

333/400/533 Mbps

2500 Mbps CPUCoreIP x 2

Bus InterfaceIP

PCIExpress IP

SATA IPDRAMSRAM

Cache IP

USB2.0IP

800 Mbps

480 Mbps

333/400/533 Mbps3000 Mbps

PLLPLL

PLL

PLL

PLL

DD

RC

ontr

olle

r IP

DD

RC

ontr

olle

r IP

PLL


LowSpeed

=

+

=

• Test development time is long because of differences between DUT behavior in design and ATE

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

• Test times are long because multiple pattern executions are required looking for a pass or must capture/post-process

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

Stored Response ATE

IP Re-use


Protocol Aware ATE ApplicationsPotential Areas of Interest

ImproveFault

CoverageAnd DPM

ImproveEarly

SiliconYield

Speed UpSiliconDebug

ReduceCustomer

ReturnDebug Time

ProtocolAwareATE

Time toMarket

ProductionEconomicsQuality

ReduceTest Time

Reduce PgmDevelop &

Debug Time

Reduce orEliminateSystem

Level Test

Reduce DIBComplexity


Protocol Aware ATE Application:Reduce or Eliminate System Level Test

ImproveFault

CoverageAnd DPM

ImproveEarly

SiliconYield


ReduceCustomer

ReturnDebug Time

ProtocolAwareATE

Time toMarket


ReduceTest Time

Reduce PgmDevelop &

Debug Time


Level Test



Example of World-Class ASICATE Test Fault Coverage

- At the 2007 VLSI Test Symposium a major ASIC vendor (IBM) described fault coverage for their ASICs

- Stuck-at fault coverage was very high at >99% (DC-Start and DC-end)

- Transition fault coverage was lower at 84-87% (Scan, ASST, TADT)

- No functional tests were performedIBM ASIC Fault Coverage – VLSI Test Symposium 2007


Example of ASIC ATE Test Fault Coverage Issues

- At the same conference a major ASIC customer (Cisco) described their experience with ATE test escapes on ASIC failures at system test

- Of the ASIC failures identified at system test 68% were attributed to ATE test escapes

- Cisco attributed the high percentage of ATE test escapes to:- Hard to emulate functional environment with a standalone chip

- Board functional tests run different data from ATE ASIC BIST

Cisco ASIC Fault Coverage – VLSI Test Symposium 2007


Cycle-based vs Protocol-based

ATE is like coding in machine language Bench equipment is like programming in assembly or high-level languageCharacteristics of new interfaces

• Asynchronous

• Non-deterministic

• Interactive (needs some sort of handshaking, eg, speed negotiation, because they have to be backward compatible)

Non-deterministic number of skips and idles


2nd PCCat-5 cable

PC motherboard

Customized LAN cardDUT in socket

Processor/PCIE controller

PCIE slot

PCI Express(PCIE):System Level Module Test Example- Semiconductor manufacturer wants to test thru PCI Express port on ATE:- Send commands to Device Under Test (DUT) through the PCIE port to set up registers- Write and read back the register values across PCIE interface- Send commands thru the PCIE port to set up internal loopback thru 1000BaseT ports- Send data thru the PCIE interface and loop it back- Check the data to verify that the entire chain is OK

- Instead they have to test in a separate System Level Test (SLT) insertion- Separate System Level Test (SLT) insertion using 2 PC’s and a customized LAN card- Throughput is much slower than ATE- The SLTs are inexpensive but take up a lot of floor space


DUTATE

Device Internal loopback

1000BaseTPCIEATE would need to:1.Initiate and complete handshake to establish link

2. During subsequent exchange, handle low level link layer/physical layer functions such as inserting “skips” (and perhaps resending packets/commands) without user intervention

3. Designer would only need to provide “Payload Data” and the tester would manage the link, just like CPU/PCIE controller

PCI Express(PCIE):Desired ATE Setup


ImproveFault

CoverageAnd DPM

ImproveEarly

SiliconYield


ReduceCustomer

ReturnDebug Time

ProtocolAwareATE

Time toMarket


ReduceTest Time

Reduce PgmDevelop &

Debug Time


Level Test


Protocol Aware ATE Application:Speed Up Silicon Bring-up and Debug


Non-Deterministic DUT Behavior:Cycle Slipping

SOC

ARM PROC

Ext MemI/F

AsyncBoundary DDR

BusDebugPort

PLL PLL

TimingDomain#1

TimingDomain#2

Random Phase Alignment

ATE T0 Reference

Debug Bus CMD

Tester T0 Ref

DDR Write (early)DDR Write (nominal)DDR Write (late)

Tester starts in alignment

Results may appear on DDR bus at any of several cycles.Where do you place your strobe?


Non-Deterministic DUT Behavior: Asynchronous Memory BIST

BIST Control

ADDR

CTL

Data

FaultPacket

“Go!”

…

…

…

How can you capture only the fault packets across multiple memories?

BIST Control

ADDR

CTL

Data

FaultPacket

BIST Control

ADDR

CTL

Data

FaultPacket

BIST Control

ADDR

CTL

Data

FaultPacket

FaultPacket

FaultPacket

…

…

…

…

…

…

Memory Array

Memory Array

Memory Array

Memory Array

BIST Clock

Status

Fault Packets


Silicon Debug:Direct Register Read and Write

JTAGOr

DebugIF

DeviceLogicBlockDevice

LogicBlock

DeviceLogicBlock

DeviceLogicBlock

DeviceRegister

File

Write.jtag ( ADDR: 04h, DATA: 55h)Read.jtag (ADDR: 0Ah, DATA read_var)

What you want to do!Directly Read & Write device registers using the same protocol as RTL and bench tests

What you have to do!Debug using ATE Patterns at a much

lower, bit oriented level: ’01HL’

- A single line of RTL becomes multiple vectors as it is translated into serial machine cycles

- ATE vectors are difficult to debug, difficult to modify, difficult to communicate to design engineers

Device ProtocolProtocol

Transactions ATE VectorsCode

CompressionJTAG 1 74 98.65%

USB2.0 7 392 98.21%MDIO 2 78 97.44%

I2C 4 124 96.77%PCIE 12 256 95.31%

DDR2 4 20 80.00%#of Vectors/PA Transactions for 1 x 32 bit register transfer


• Interactive sequences of Protocol frames can be strung together.

• Interactive Register Read/Write from Debug Environment

• For some protocols, no patterns are necessary (slower serial: MDIO, JTAG).• Simulation RTL and bench tests are protocol specific

• Translation to ATE is still protocol specific. Debug occurs in protocol domain. TheHdw.Protocol.Port.Enable “MDIOport,CLOCKport”clk.Resetmdio.Writec22 phy := 28, reg := 2, data := &HB57E ‘ Setup BIST Engine.mdio.Writec22 phy := 28, reg := 3, data := &H5007mdio.Writec22 phy := 29, reg := 1, data := &H0001 ‘ Start BIST Engine.mdio.ReadUntilc22 phy := 20, reg := 8, data := &h0000 ‘ Wait for BIST to Stop (assuming a status word).Dim result As SiteLong ‘ Read device test status.result = mdio.Readc22 phy := 20, reg := 7mdio.Stopclk.StopTheExec.Flow.TestLimit result, lo := 0, hi := &H0030 ‘ Test result.19

Silicon Debug:Patternless Test Generation


SOC ATE Digital Instrument:Existing SOC Architecture

Standard SOC Digital Instrument

DSSCLogic

PatgenT

TTiming

Pin Electronics

PEHost

Computer DUT

Standard SOC Digital Instrument• Appropriate voltage specs, and data rate• Logic pattern generator with associated pattern memory• Digital Signal Source and Capture• Programmable edge timing• Microcode control over analog and DC instruments• Pattern execution controlled by Host Computer


Protocol Aware Digital Instrument

DSSCLogic

PatgenT

TTiming

Pin Electronics

PE

Select between normal PE operation and Protocol Engine

HostComputer

Protocol Aware Channels

FPGA Based

DUT

Protocol Aware Digital Instrument = Standard SOC Digital InstrumentPLUS

• Separate FPGA based Protocol Engines• Separate memory for Protocol transactions• Patgen and Host handshaking (start/done)• Transaction execution from Host Computer, Job Program, or Transaction Memory• Slow Serial Master (JTAG etc)• RAM Emulation for DDR or Boot PROM• Master/Slave operation

SOC ATE Digital Instrument:Protocol Aware Architecture


First Generation Protocol Aware ATE already exists

• Limited Protocol Aware ATE capability is available today• A first generation Protocol Aware Instrument is the UltraFLEX SB6G

– Designed for at-speed test of High Speed Serial buses like PCI Express and SATA– SB6G can recognize, manipulate, and compare 8b/10b encoded DUT output data up to 6.4Gbps

6.4Gb/s Data Rate

ClockData

Recovery

10 bitAlign

20 bitMatch

Disparity & Symbol Map

RAM

SB6G Timing and Data Alignment Compare Vector Data

Capture for Out-of Order

Data Compare

Compare PRBS Auto-seed

DUT output: 8b/10b encoded data @ up to 6.4Gbps

Time align to incoming data

Data align to specific 8b/10b Symbol Boundary

Data manipulation- Ignore Idles- Map +/- disparity- Re-map symbols

Data align to a specific two symbol sequence

- At-speed comparewith stored pattern

- At-speed comparewith PRBS pattern

- Capture for latercompare withOut-of-Order data

DUT Output Data

Protocol Aware Capability

Data manipulation- Ignore Idles- Map +/- disparity- Re-map symbols

Data align to a specific two symbol sequence


The Future of ATE is Protocol Aware

• Over Time ATE will become Protocol Aware, not just stored-response patterns

• Potential Protocol Aware ATE capabilities include:– Transactional level software so design and test interact with the device at the same high level of abstraction.

– Low latency DUT<-> ATE handshake to support higher level functions like memory (RAM/Flash/ROM) emulation.

– Dealing with non-deterministic DUT behavior - timing shifts, idles, & out-of-order data– Supporting at-speed functional test in device native operating mode (Mission Mode)

• Protocol Aware ATE can:– Reduce test development time with transactional level ATE software– Improve early silicon yield because ATE matches device Mission Mode– Reduce test time by eliminating the need for capture and post-processing– Increase fault coverage by testing devices in Mission Mode– Reduce or eliminate the need for System Level Test and DIB Circuitry


Questions?

Protocol Aware ATE

protocol aware ate semi submitted

Technology

protocol level of abstraction

debug protocol aware

system level test speed

usable design ip

low level vectors

ip blocks

test engineer hell6533

devices easier