Phone Conference P1450

Meeting discussion

0. IEEE meeting clearances

Nothing under discussion or presentation for this meeting was

identified as being proprietary or restricted.

1: Fail Feedback

Open issue about "Fails collected" -- whether the 'range' of a fail

report is over the entire referenced Pattern, or a sub-range of the

Pattern.

Talked about a "Masked Data" concept; a mechanism to modify pattern

data from a parallel block, to identify which comparisons were

performed and/or which comparisons were not performed. This parallel

mask block would be referenced with the Pattern in the PatternBurst,

or perhaps referenced from a FailData block, and would indicate when

comparisons are active (or not) in that Pattern.

Presented the notion of using Start and Stop as providing this range

information, either as part of the PatternBurst or maybe under

FailData.

Tony asked Peter what would happen if a fail environment reported only

half the patterns were run? Peter responded with the following

scenario: when ATPG defines a pattern set, IF at that time you

indicate what you can measure, and then when you return fail data it

is over the same environment that it was generated, then diagnosis

flows work well. BUT if you generate tests for MORE outputs and then

report fails over LESS outputs, the diagnosis process is very much at

risk. It is important that the pattern-data loaded to be used for

diagnosis, align with the information being reported in the fail data,

for proper diagnosis.

Part of the discussion identified that some of these behaviors (for

instance, masking sets of signals or ranges of vectors) is performed

optimally in the ATE environment (with dedicated operations). The

question was raised: Do we want tester overrides to be performed, and

report the override conditions back as part of the fail report, or do

we report back against a specification of the pattern data as it was

run on the tester?

The current proposal from the Working Group at this time is that if a

subset of a Pattern is run, or any modification made to the pattern

under execution, then the environment that modified that pattern data

is responsible for generating a STIL pattern that reflects that

modification for use in diagnosis. For instance, if only a subset of a

Pattern is executed, then that subset is identified as the Pattern to

be used for diagnosis.

Tony raised a new perspective on additional information that may be

associated with fail-data. When patterns fail they may have been run

under a characterization flow, varying voltage, speed, etc. What

additional parameters or information should we pass back in this

process to assist in identifying what condition or set of conditions

may have caused this failure? Dan referenced the 1450.3 Resource tag

as a mechanism to identify what resources may be modified. The

discussion of this issue opened into a broad discussion of general

data-logging issues, and the Working Group agreed to not go down that

path at this time. No proposal for additional constructs was made,

although Greg represented that the Ann could maintain the data (outside

of tool knowledge of the contents).

Jim had a concern that additional data may be desirable at a failure

location, in particular, a "vector index" representing a tester memory

offset in addition to a "cycle count", to present both of the indexes

common to ATE equipment in locating a failing location. Part of his

concern related to potential variations in cycle count, for instance

through MatchLoops. Counter discussion identified that the pattern

label placement is key to unambiguous identification of failing

locations, as has been previously discussed. Jim took [AI1] to

consider a proposal for additional referencing-information.

2: Ready for ballot

Tony identified that our goal at the ITC meeting on Sept. 29 is to

move this proposal to balloting. All Working Group members took [AI2]

to actively review the current proposal for any issues, and present

issues at the next meeting before the ITC meeting.