Greg Maston (chair & scribe)

Tom Bartlestein

Jason Doege

Peter Wohl

  Jason identified the requirements to identify the bounds of pattern

unit, where "pattern" is interpreted to be an independent unit of

test operation. The scan data load operation can be redundant (when

two pattern units featuring a common load-unload operation are

separated), but the unload data can be present only once in an

unmerged context. Hence some sort of label modifier to identify

sub-operations in the load and unload behaviors.

  Greg indicated that he saw two separate purposes being expressed here

- one is to identify the failure location data, and the other is to

identify independent units of a test. His concern is that the two

purposes may not share a common solution.

  Peter stated he sees two purposes as well, the first being to provide

fail feedback to the tool, and all the tool needs is a "pin" and a

"pattern".  We need to provide a standard language to receive fail

data information for tools, and we need to put in language constructs

to help translate from what the tester provides to what the tool

needs.

  Jason identified that it was his hope that there would be no

translation needed, that the standard would define the clues in the

file such that no translation process was required.

  Which ensued the following discussion about how to identify the

failing pattern block back to the test environment. We explored the

lack of the current STIL definition around a "pattern" (as defined

above), explored the relationship of patterns to measure-states, and

elaborated that loads are not independent; in sequential ATPG contexts

multiple loads are order-sensitive and may see multiple captures.

  Which evolved to a pattern is an arbitrary boundary with some set of

characteristics, possibly containing a single unload and measure or

maybe multiple unload and measures.

  The Working Group then established that we need to identify

boundaries in a pattern (STIL term), but do not need necessarily

"pattern" (ATPG term) boundaries. Really want to know where one

ATPG pattern's drive events start and where that same pattern's compare

events start. For a pattern to be diagnosis-friendly, must have these

boundaries. Another view of this was that there are two boundaries in

ATPG -

 1. reset a state

 2. perform a measure

  In basic-scan these are the same; in complex sequential patterns

  these two operations don't coincide.

Tom raised the perspective that for scan-unloads this is good. But

concern with po measures, and in particular, multiple po measures.

  One option here is a simple X statement with drive-events and

compare-events, and to count offsets from the compare marker. This

puts the burden of the translation process back to the atpg to count

offsets and identify ATPG-pattern behaviors at those points.

  Peter identified the concern that some POs are used as a PO and

scan-out, complicating the interpretation from "scan" or from

"measure". Also if the scan is executed as flat vectors need to

translate back to shift.

  Which led to the following ground rule: modifying the patterns at

test (for instance flattening scan) without maintaining whatever

marker information we end up defining, will disallow diagnosis of

those modified patterns, at least directly. If the tool can read the

modified patterns back in, then that data will need to be provided to

be able to diagnosis from that format.

  The perspective that if the ATE is to calculate something (for

instance an offset), then the ATPG needs to provide the information

of what and how to calculate that information. Peter stated a desire

that from a given boundary X statement, he wants to see pin #, cycle #

(5th cycle of the 12th unload on this pin).

  Jason doesn't want to translate, and wants explicit markers in the

patterns. Can't expect ATE to calculate and get it right.

  Bruce considered the following "boundary items": load, unload,

capture (maybe multiple capture).

  The group considered two markers :

-  unload marker

-  parallel measure marker

with a count from the preceding closest marker returned for failures,

and an implicit marker at the start of a pattern set (to support existing

pattern sets without explicit markers).

   The concept to extend identifiers was proposed:

(a) in straight-line code:

    X "33"

    X "33.unload"

(b) in proc call

    X "33" 

    Call ... -> contains X "unload"  ==>  X "33"."unload"

where the marker extension is reset in straight-line code when the

procedure returns.

The presence of a "." was used in discussions but any separator could

be used here (and "." is not good because of STIL string-concat

behavior).

................

Tom raised one more concern before the group closed, which is that

when diagnosing fail data it is important to also know what

passed. He made a request to add a "range of patterns" information to

the fail data to indicate that the contained failures were all found

within a range of the test, in case the test execution was aborted

without all of the test program being run (because, for instance, a

fail-reporting limit was hit).

old

[AI1] Greg - generate examples requested at 6/27 meeting