Adapting IEEE 1687 PDL for Writing Analog Tests

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




� 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




� 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



2 Command keyword to specify response

12

iRead Register|Pin [Value]

- Registers don’t apply to analog- Pins okay, may need nodes


Problem 3: specifying response range




3 High/Low range for expected measure value

13


Only compares to a single value; analog response often requires upper/lower range

Problem 4: representing real numbers





4 Representation of analog values with real numbers

14




Problem 5: representing units






5 Representation of analog values with units

15


Only allows binary, hex, decimal numbers with no notion of units


Problem 6: quantizing analog values







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








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









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










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










9 Add analog commands to PDL Level 0

20 Did you see the elements which need to be extended?

Outline




� 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




� 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

Date post:	18-Mar-2022
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Adapting IEEE 1687 PDL for Writing Analog Tests

Documents