Integrating Physical Test Into The IC Studio Workflow

Integrating Physical Test into the IC
Studio Workflow
Harry Peterson
Senior Director of IC Technology
Pixelworks Inc
Co-authors:
Angus Tang
Marc Ranger
Introduction
■ Trends:
— What we can build is limited by our ability to manage
complexity
— Co-design is everywhere
— Schedules keep shrinking
— Interaction among disciplines becomes tighter
— Simulators are more powerful
— ATE becomes relatively more expensive
■ Focus of this presentation:
— Methodology for co-design of test program and mixed-
signal chip
2
HWP, Integrating Physical Test into the IC Studio Workflow, March 2007
Objective:
Minimize Time to (Profitable) Revenue
■ We must produce first-time-right mixed-signal

designs that are testable and cost-effective.
■ At the same time, we must deliver first-time-
right test capability that is comprehensive
and cost-effective.
3
The Idea
■ Create two views for the testbench:

— Virtual
— Physical
■ By making it easy to flip between these two

representations, we speed up the
development and verification of mixed-signal
test programs.
4
Methodology
■ Instantiate both the physical and virtual view

of the testbench.
■ Create a pipe between these views.
■ Use views interchangeably in order to
validate and optimize both.
5
Testbench, in the virtual world
■ Resources for generating stimuli:
— Dozens of types of signal generators exist
— For this session, we just look at PWL and
PULSE
■ Resources for analyzing responses:
— EZWave
— Third-party (Kimotion) software mines data so
that we can automate regression tests
— Custom scripts bridge the gap between
Simulation software and ATE software
6
Testbench, in the real (ATE) world
■ Resources for generating stimuli:
— AWG (Arbitrary Waveform Generator)
— Pin Driver
— Other
■ Resources for analyzing responses:
— Waveform digitizer
— Comparator
■ Other resources:
— Active load
— Active and passive circuits on load board or probe card
7
EDA Tool Selection
■ Why we chose ADMS:
— Allows us to efficiently move between accurate
transistor-level analysis and fast top-level
analysis.
— Efficient
■ Why we chose IC studio:

— Good schematic-capture
— Gracefully accommodates a variety of other
views and resources
— Open
8
ATE Resource Selection
■ Credence D10
— Powerful mixed-signal capability
— Good analog performance
— Open C++ style programming interface
— Well-suited to characterization as well as to

production testing
— Low cost
9
Test Generation Methodology / Digital
■ Digital designers figured this out long ago.

■ But their problem was simpler:
— Simply translate simulation data files into test
vectors for ATE tester
■ Examples of such vector translation tools:
— VTRAN
— V2SCO
10
Test Generation Methodology (Mixed-signal)
■ Transfer of simulation data to tester program is

largely a manual process.
■ We need a more automatic transfer mechanism.
■ The concepts have been considered, but have not yet
been widely integrated into the workflow.
■ References:
— [1] Viekko Loukusa. “Behavioral Test Generation Modeling
Approach for Mixed-signal IC Verification,” Proceedings of
International Mixed-Signal Testing Workshop 2002
— [2] Geert Seuren, et al, “Extending the Digital Core-Based
Test Methodology to Support Mixed-Signal,” Proceedings of
International Test Conference, 2004
11
Enabling technology for mixed-signal test
ICStudio
■ An integrated, user-friendly environment
■ Create, manage, and simulate design at

different levels of abstractions (Spice,
schematics, HDL)
■ Facilitates behavioral modeling and mixed-
level simulation
12
Approach
■ Create top-level testbench to verify design in

simulation.
■ Top-level simulation is made possible
through the use of behavioral models.
■ The test bench is then used to generate the
main components of the ATE test program,
these includes the test vectors and tester
instrument setups.
13
Case Study: video AFE
■ Consists of the following blocks:

— Signal pre-conditioning
■ Input buffers
■ Clamps
■ Gain/Offset DAC
— Three fast ADCs
■ 10-bit resolution
■ 162MSPS
— Timing recovery circuit
■ Line-locked PLL
14
DUT and the Simulation Testbench /1
Digital stimulus
Verilog
ADC
under
Test Monitors
Analog stimulus Spice & Verilog AMS

Verilog AMS
15
■ The top-level testbench allows us to characterize the
ADC and extract important performance parameters
such as INL, DNL, and ENOB.
Digital stimulus
Verilog
ADC
under
Test Monitors

Verilog AMS
16
■ The digital stimulus block generates the
necessary clock and control signals to the ADC.
■ Digital stimuli are implemented as a Verilog
block.
Digital stimulus
Verilog
ADC
under
Test Monitors

Verilog AMS
17
■ The analog stimulus block generates a ramp
signal so that the output of the ADC can be
measured for linearity. Analog stimuli are
modeled behaviorally in Verilog AMS.
Digital stimulus
Verilog
ADC
under
Test Monitors

Verilog AMS
18
Case Study: video AFE
19
Mapping the simulation testbench
to the ATE testbench /1
■ The digital stimuli are translated into test
vectors in ATE tester format.
■ The digital module of the D10 tester accepts
test vectors in STIL format, which can be
readily generated from simulation.
20
Top-level Test Bench
Test_Bench_behavioral.va
.
.
. Analog stimulus
//ramp input
Verilog AMS
module single_ended_ramp (.amplitude(1.0), .offset(0.5)...) Ramp(Rin_0, VSSA);
. v
.
. t
ADC_Test.cpp
.
.
.
void AWG_setup(double amplitude, double offset, string signal...)
{
/*********************************** AWG SETUP ***************************************/
. Sapphire D-10
. AWG
cscTester->AWG()->Signal(signal)->OutputCtrl()->setOptimization(OPTIMIZE_FOR_NOISE);
cscTester->AWG()->Signal(signal)->OutputCtrl()->setAmplitude(amplitude);
cscTester->AWG()->Signal(signal)->OutputCtrl()->setCommonOffset(offset);
cscTester->AWG()->Signal(signal)->OutputCtrl()->setClockFrequency(awg_freq);
cscTester->AWG()->Signal(signal)->WaveformCtrl()->setSource(AWG_WAVEFORM_MEMORY);
cscTester->AWG()->Signal(signal)->WaveformCtrl()->setActiveWaveform(wfid);
cscTester->AWG()->Signal(signal)->WaveformCtrl()->setWaveformRepeat(ULONG_MAX);
.
.
}
.
.
21
■ Using the method described, the bulk of the
ATE test program can be generated from the
simulation testbench, before first silicon is
available.
■ Test program development time and effort is
reduced.
■ This flow bridges the communication gap
between test engineers and designers.
22
Next steps
■ 1. Integrate the Kimotion ‘Breaker’ tool into this flow,

in order to more tightly close the loop between
‘executable spec’ and verified Silicon.
■ 2. Adopt Mentor ‘Checkerboard’ tool in order to gain
the efficiency and quality benefits of greater
automation and faster simulation.
■ 3. Pull software development and validation into the
co-design and product-verification loops.
■ 4. Integrate Yield Analysis and Product Engineering
capabilities.
23
Next steps /1
Use Kimotion ‘Breaker’ tool to help mine simulation data
so we can make specs more executable
Design variables Specifications Process and Environment
■ User-defined
testbenches measure
important circuit
performances Eldo
■ Breaker exercises KtModels
testbenches to find AdvanceMS
most likely and/or …
worst-case violations
for each performance
Performance models Optimized netlist Specification corners
24
Next steps /2
Use Mentor ‘Checkerboard’ tool to greatly improve speed
and effectiveness of chip-level simulation
Verification engineer traditionally has access to two types of block descriptions
■ .
Transistor-accurate netlists Ideal behavioral models are fast, but
slow, but capture all effects modeling extra effects requires tuning
vdd
X6
vdd vdd biasgbp biasp
m3a biasp m3b vss vss casgbp casp
.param cload=2.5p l={l3} w={w3} m={mout+min} l={l3} w={w3} m={mout+min} n2a in casgbn casn
caspa caspb
caspa out biasgbn biasn
outn outp C7 C8 gainboostp
C1 C2
{cgbp} {cgbp}
vss
{cload} {cload}
n2b X5
vss
n2a
vss vss casgbp casp
n2b in casgbn casn
m4a m4b
vdd caspa caspb vdd caspb out biasgbn biasn
l={l4} w={w4} m={mout} l={l4} w={w4} m={mout}
gainboostp
outn outn outp outp X3
A
C3 C4 vdd vdd biasgbp biasp
vss vss casgbp casp
{ccm} {ccm} n3a in casgbn casn
cmreg
casna out biasgbn biasn
gainboostn
casna casnb
l={l2} w={w2} m={min} l={l2} w={w2} m={min}
inp vss vss inn m5a m5b
m2b m2a X4
casna casnb
vss vss casgbp casp
n1a C5 C6 n3b in casgbn casn
n3a n3b
casnb out biasgbn biasn
{cgbn} {cgbn}
gainboostn
vss vss
biasn2 biasn2
m1a m1b l={l6} w={w6} m={mout} cmreg l={l6} w={w6} m={mout}
BIASING
m6a m6b vdd vdd biasp biasp
outp outp X7
vss vss casp casp
outn outn reg
ibias ibias casn casn
cmout ref
biasn2 biasn2 biasn biasn
vss
X2
Checkerboard verification avoids the need for full spice simulation

vdd
X6
l={l3} w={w3} m={mout+min} l={l3} w={w3} m={mout+min} n2a in casgbn casn

.param cload=2.5p caspa caspb
C1 C2
{cgbp} {cgbp}
vss
{cload} {cload}
n2b X5
vss
n2a
vss vss casgbp casp
n2b in casgbn casn
m4a m4b
gainboostp

Captures impact of
vss vss casgbp casp
cmreg
gainboostn
casna casnb
m2b m2a X4
casna casnb
vss vss casgbp casp
n3a n3b
{cgbn} {cgbn}
gainboostn
vss vss
biasn2 biasn2
BIASING
outp outp X7
vss vss casp casp
outn outn reg
cmout ref
vss
X2
block’s effects
on system behavior
vdd
X6

caspa caspb
C1 C2
{cgbp} {cgbp}
vss
{cload} {cload}
n2b X5
vss
n2a
vss vss casgbp casp
n2b in casgbn casn
m4a m4b
gainboostp

vss vss casgbp casp
cmreg
gainboostn
casna casnb
m2b m2a X4
casna casnb
vss vss casgbp casp
n3a n3b
{cgbn} {cgbn}
gainboostn
vss vss
biasn2 biasn2
BIASING
outp outp X7
vss vss casp casp
outn outn reg
cmout ref
vss
X2
Does not capture

System block diagram

vdd
X6
interactions
caspa caspb
C1 C2
{cgbp} {cgbp}
vss
{cload} {cload}
n2b X5
vss
n2a
vss vss casgbp casp
n2b in casgbn casn
m4a m4b
gainboostp

vss vss casgbp casp
cmreg
gainboostn
casna casnb
m2b m2a X4
casna casnb
vss vss casgbp casp
n3a n3b
{cgbn} {cgbn}
gainboostn
vss vss
biasn2 biasn2
BIASING
outp outp X7
vss vss casp casp
outn outn reg
cmout ref
vss
X2
25
Next steps /3
Pull software development and validation
into this codesign loop
■ In the virtual world: tools already support this.

■ In fact, a few people have been doing this (with huge
success) for about twenty years.
— Example: Andy Bechtolsheim’s team at Sun ran code and
booted the Sparc 1 chipset before they actually taped it out.
■ In the physical world: ATE resources to support this flow
have been widely available for only about two years.
— Example: D10 (Credence)
— Trend: Open ATE initiative is gaining mainstream support
reference:
http://www.semitest.org/news/articles/FF_19_Yuhai_Ma_05.pdf
■ The bottom line: for many products, it is possible to do
validation (including software validation) at probe test. This
speeds up development schedules.
26
Next steps /4
Integrate yield-analysis and
product-engineering capabilities
■ Yield Analysis Options
1. Corners Analysis
■ Corners are based on digital performance criteria
■ Requires many simulations
■ Leads to overdesign – more so with newer processes
1. Classic Monte Carlo Analysis

■ Best accuracy
■ No overdesign
■ Requires a prohibitive number of simulations
2. Monte-Carlo with KtModel Analysis

■ Requires a limited number of simulations (user controlled)
■ Model evaluations replace simulation in monte-carlo loop
■ No overdesign
27
Next steps /4
Integrate yield-analysis and
product-engineering capabilities
■ KtModeler improves
the accuracy of
behavioral models.
— Behavioral
simulations can see
issues previously
caught only with spice
simulation.
■ KtModeler can also be

ADVance MS
used instead of V-AMS Spice Fastspice Verilog
simulator in monte-
carlo runs.
— Reduces the number
of simulations
required for monte-
carlo by 10-100x
28
Acknowledgements
■ Pixelworks executive support:
— Hans Olsen
■ Pixelworks engineering team:
— Jenkin Wong, Thomas Nasralla, Mike Parrish, Jay Sulima,
Pri Nallahandi, Liang Yuan
■ Insyte (ATE Consultant):
— Peter Lindholm
■ Mentor:
— Sam Wasche, Christian Mayer, Brandon Barnes,
Vamsi Rachapudi
■ Credence:
— Ken Skala
■ Kimotion:
— Bart De Smedt, Walter Daems
29
30

Integrating Physical Test Into The IC Studio Workflow

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Integrating Physical Test Into The IC Studio Workflow

Uploaded by

Copyright:

Available Formats

Integrating Physical Test into the IC

■ We must produce first-time-right mixed-signal

■ Create two views for the testbench:

■ By making it easy to flip between these two

■ Instantiate both the physical and virtual view

■ Why we chose IC studio:

— Open C++ style programming interface

— Well-suited to characterization as well as to

■ Digital designers figured this out long ago.

■ Transfer of simulation data to tester program is

■ Create, manage, and simulate design at

■ Create top-level testbench to verify design in

■ Consists of the following blocks:

Analog stimulus Spice & Verilog AMS

Analog stimulus Spice & Verilog AMS

Analog stimulus Spice & Verilog AMS

Analog stimulus Spice & Verilog AMS

■ 1. Integrate the Kimotion ‘Breaker’ tool into this flow,

Performance models Optimized netlist Specification corners

outn outn outp outp X3

Checkerboard verification avoids the need for full spice simulation

outn outn outp outp X3

outn outn outp outp X3

Does not capture

outn outn outp outp X3

■ In the virtual world: tools already support this.

1. Classic Monte Carlo Analysis

2. Monte-Carlo with KtModel Analysis

■ KtModeler can also be

You might also like