Post on 18-Mar-2022
Adapting IEEE 1687 PDL for Writing Analog Tests
… an ongoing work by the informal analog test collective of:
Jeff Rearick (speaker)Steve Sunter
Peter Sarson
Hans Martin von StaudtNeil Macmillan
Heiko Ahrens
Ralf ArnoldStefan Vock
Mustapha Slamani
Ken Butler
Vladimir Zivkovic
Salem Abdennadher
Ken Ferguson
Ian Harrison
Marco Spinetta
Ronny Vanhooren
Marc Hutner
Outline
� Background and motivation
� The problems with PDL in representing analog tests
� Analog PDL proposal
� Conclusions
2
Outline
� Background and motivation
� The problems with PDL in representing analog tests
� Analog PDL proposal
� Conclusions
3
Background and Motivation
� Post-ETS 2014: Informal group tackling two topics:
• Analog DFT• Analog fault coverage measurement
� Progress so far:
• Streaming access to ADC/DAC via 1687 (ITC’15)• Analog test bus (VTS’16)• Analog PDL (today’s topic)
� Application of analog test bus to automotive
• 0-DPPM targets imply thorough test, including analog• Structured test approach for analog circuits• Re-usable tests facilitate best-practice testing
4
IEEE1687 overview
� IEEE Standard for Access and Control of Instrumenta tion
Embedded within a Semiconductor Device
• Describe network architecture for access to on-chip instruments• Provide portable pattern format for controlling instrument
operation • IEEE 1687 standard published on December 5, 2014
� Observation:
• The standard doesn’t say “no analog”…
iJTAG
Clever idea: extend IEEE 1687 to help with analog t esting5
Two key premises: 1687 for analog
1. Analog instruments use digital control (and sometimes digital data)
2. Analog instruments are operated with procedures
iProc force_voltage {v_nom} { … }
iProc measure_current {i_sc} { … }
iProc time_RC_decay {V_targ, Vdd, 10, 90} { … }
iProc set_pre_tx_emphasis {2x} { … }
How does this map to IEEE 1687?
A_out_instr…
A_in_instr
…
6
Two Components of IEEE1687
1. Hardware (ICL)� The on-chip network, largely based
on digital circuits and serial access,but extensible
2. Software (PDL)� IP-level procedures which operate
the instruments� Applications to retarget those IP-level
patterns to the SOC level iProc force_voltage {v_nom} { … }
A_in_instr
…
Clear application for IEEE1687 for this type of ana log testing!7
Analog Test Bus PDL (from VTS’16)
A_out_ckt
A_in_instr
…
…
# test the voltage output from the charge pumpiProc run_analog_test1 { } {
iCall start_charge_pump {A_out_ckt)iCall measure_voltage
}
# start the charge pump and connect it to the analog test busiProc start_charge_pump { } {
iWrite A_out_ckt.start 0b1iApplyiRunLoop 1000iWrite A_out_ckt.out_enable 0b1iApply
}
# measure the voltage on the analog test busiProc measure_voltage { } {
iWrite A_in_instr.out_enable 0b1iWrite A_in_instr.activate 0b1iApplyiRunloop 100iRead A_in_instr.scan_regiApply
}
8
Outline
� Background and motivation
� The problems with PDL in representing analog tests
� Analog PDL proposal
� Conclusions
9
Analog Test Bus PDL (from VTS’16)
10
A_out_ckt
A_in_instr
…
…
# test the voltage output from the charge pumpiProc run_analog_test1 { } {
iCall start_charge_pump {A_out_ckt)iCall measure_voltage
}
# start the charge pump and connect it to the analog test busiProc start_charge_pump { } {
iWrite A_out_ckt.start 0b1iApplyiRunLoop 1000iWrite A_out_ckt.out_enable 0b1iApply
}
# measure the voltage on the analog test busiProc measure_voltage { } {
iWrite A_in_instr.out_enable 0b1iWrite A_in_instr.activate 0b1iApplyiRunloop 100iRead A_in_instr.scan_regiApply
}
How does the test writer say that he expectsthe charge pump output to be 1.2V?
That’s all well and good, but…
Problem 1: specifying stimulus
# Issue with IEEE 1687 PDL
1 Command keyword to specify stimulus
11
iWrite Register|Pin Value
- Registers don’t apply to analog- Pins okay, may need nodes
Only allows binary, hex, and positive whole numbers (decimal) which is too limiting for analog
Problem 2: specifying response
# Issue with IEEE 1687 PDL
1 Command keyword to specify stimulus
2 Command keyword to specify response
12
iRead Register|Pin [Value]
- Registers don’t apply to analog- Pins okay, may need nodes
Only allows binary, hex, and positive whole numbers (decimal) which is too limiting for analog
Problem 3: specifying response range
# Issue with IEEE 1687 PDL
1 Command keyword to specify stimulus
2 Command keyword to specify response
3 High/Low range for expected measure value
13
iRead Register|Pin [Value]
Only compares to a single value; analog response often requires upper/lower range
Problem 4: representing real numbers
# Issue with IEEE 1687 PDL
1 Command keyword to specify stimulus
2 Command keyword to specify response
3 High/Low range for expected measure value
4 Representation of analog values with real numbers
14
iWrite Register|Pin Value
Only allows binary, hex, and positive whole numbers (decimal) which is too limiting for analog
iRead Register|Pin [Value]
Problem 5: representing units
# Issue with IEEE 1687 PDL
1 Command keyword to specify stimulus
2 Command keyword to specify response
3 High/Low range for expected measure value
4 Representation of analog values with real numbers
5 Representation of analog values with units
15
iWrite Register|Pin Value
Only allows binary, hex, decimal numbers with no notion of units
iRead Register|Pin [Value]
Problem 6: quantizing analog values
# Issue with IEEE 1687 PDL
1 Command keyword to specify stimulus
2 Command keyword to specify response
3 High/Low range for expected measure value
4 Representation of analog values with real numbers
5 Representation of analog values with units
6 Quantizing analog values
16
Test data register1
DACAnalog circuit ADC
Test data register2
Expected analog values here need to be mapped to digital values to unload from TDR2
Desired analog values here need to be mapped to digital values to load into TDR1
Problem 7: streaming DAC/ADC data
# Issue with IEEE 1687 PDL
1 Command keyword to specify stimulus
2 Command keyword to specify response
3 High/Low range for expected measure value
4 Representation of analog values with real numbers
5 Representation of analog values with units
6 Quantizing analog values
7 iStream command keyword for DAC/ADC wrappers
17
Test data register1
DACAnalog circuit ADC
Test data register2Fast streaming access is needed through these TDRs(see Sunter ITC’15 paper)
Problem 8: specifying response
# Issue with IEEE 1687 PDL
1 Command keyword to specify stimulus
2 Command keyword to specify response
3 High/Low range for expected measure value
4 Representation of analog values with real numbers
5 Representation of analog values with units
6 Quantizing analog values
7 iStream command keyword for DAC/ADC wrappers
8 Command keyword to specify precise values of time
18
iRunLoop cycle_count | time
Only specifies minimum time to spin in a wait loop; this is not a precise timing vernier
Problem 9: this all needs to be PDL0
# Issue with IEEE 1687 PDL
1 Command keyword to specify stimulus
2 Command keyword to specify response
3 High/Low range for expected measure value
4 Representation of analog values with real numbers
5 Representation of analog values with units
6 Quantizing analog values
7 iStream command keyword for DAC/ADC wrappers
8 Command keyword to specify precise values of time
9 Add analog commands to PDL Level 0
19
PDL1 is extensible, but will result in many different programing styles and commands
IEEE 1687 PDL: analog problems
# Issue with IEEE 1687 PDL
1 Command keyword to specify stimulus
2 Command keyword to specify response
3 High/Low range for expected measure value
4 Representation of analog values with real numbers
5 Representation of analog values with units
6 Quantizing analog values
7 iStream command keyword for DAC/ADC wrappers
8 Command keyword to specify precise values of time
9 Add analog commands to PDL Level 0
20 Did you see the elements which need to be extended?
Outline
� Background and motivation
� The problems with PDL in representing analog tests
� Analog PDL proposal
� Examples of an analog tests re-written in APDL
� Conclusions
21
Analog PDL proposal
# Issue with IEEE 1687 PDL Proposed solution
1 Command keyword to specify stimulus iForce
2 Command keyword to specify response iMeasure
3 High/Low range for expected measure value iMeasure node high low
4 Representation of analog values with real numbers FP & scientific notation
5 Representation of analog values with units Units (with prefixes)
6 Quantizing analog values Lookup tables
7 iStream command keyword for DAC/ADC wrappers iStream
8 Command keyword to specify precise values of time iSample
9 Add analog commands to PDL Level 0 Add above to APDL-0
22
Proposed 4 new APDL0 commands
23
� iForce• iForce Node|Pin num units [@ num units]
� iMeasure• iMeasure Node|Pin [num units [@ num units] [num units [@ num units]]]
� iStream• iStream Reg –packets <count>
� iSample• iSample Node|Pin –period <period> –samples <number_of_samples>
Optional frequency term (e.g. @ 1kHz)
Standard SI units (e.g. V,A);optional metric prefixes: f,p,u,m,k,M,G,T
Floating point (e.g. 1.2) or scientific notation (e.g. 3.125e9)
Optional other range limit
Discussion of APDL0 proposal
24
� This is still wet: the team is just starting to tackle this topic
� iForce might be split into “iForceV” and “iForceI”
� Likewise with iMeasure
� iSample needs to be thought through: freshly proposed
• The notion of exact time needs to be addressed
� APDL0’s handling of voltage and current for DC and AC (with
standard waves) seem well understood; AWG/PWL less so.
• The frequency domain needs to be addressed
� It is unclear what to do with other analog quantities (offset, gain,
linearity, rise time, jitter, noise, duty cycle, delay, distortion,
bandwidth, …): leave for PDL1?
Outline
� Background and motivation
� The problems with PDL in representing analog tests
� Analog PDL proposal
� Conclusions
25
Conclusions
� IEEE 1687 PDL needs to be extended to enable analog tests
� Analog PDL (APDL) has a solid value proposition
� APDL will provide a standard format for an IP provider to capture analog test intent that can be converted to SPICE stimulus for test content verification at the IP level.
� APDL will provide a standard format to communicate analog test intent from an IP provider to an IP integrator.
� APDL will provide a standard format for EDA tools to read and retarget from IP level to SOC level (with specific language conversions for verification and ATE and bench equipment).
� APDL will provide a standard format to describe streaming access for ADC/DAC circuits wrapping analog blocks.
� Re-usable analog tests will help achieve automotive quality levels
� We still have plenty of interesting work to do!
26