1. ITC meeting

  2. Fail Feedback proposal

  3. FailsCollected discussions

  4. Collecting all data issue

0. IEEE meeting clearances

Nothing under discussion or presentation for this meeting was

identified as being proprietary or restricted.

1. ITC meeting

ITC meeting Monday afternoon; several confirmed attendees.

2. Fail Feedback

Bruce had a question about the Pattern/PatternBurst/PatternExec

statements in the PatternFailReport. Bruce proposed putting the

PatternFail inside a PatternExec. During discussion, Peter

elaborated on the intent of the current constructs, and stated:

 (a) one PatternFailReport references a single Pattern (this is a

 fundamental requirement of the current definitions), therefore:

 (b) the Pattern statement is optional; if a tool is presented one

 Pattern and one PatternFailReport, they are assumed to be related.

 (c) there may be zero or more PatternBurst statements depending on

 the hierarchy of PatternBursts being executed to get to this pattern

 (d) there may be zero or one PatternExec reference(s).

Peter raised the concern that putting the FailReport into a

PatternExec may cause define-before-use conflicts, and may be in

conflict with original PatternExec blocks definitions. Also, by making

the fail report a top-level block it is more easily consumed in it's

own context and not dependent on the processing of the PatternExec.

Tony raised another perspective that this fail report is not intended

as a general data-logging tool. It is intended specifically for

diagnosis-linking, that is, to be consumed by a tool that is

compatible with a tool that put the reference labels (X statements)

into the original pattern data, and only that tool may be able to

consume the resulting fail report.

This resulted in some general discussion about the overall flow of

information, and who generates what (and a little bit of how).

At the end of this, Tony presented his proposed FailData statement,

starting with a review of the X statement. The X statement must be

placed in the original STIL file by the STIL writer to start the

diagnosis process (discussion of fail data in a STIL file with no X

statements present is below).

The minimum fail statement is an X-label and the failing signal.

Jason raised a question about the overlapping of load/unload

behaviors. The issue relates to the behavior that the 'unload'

operation. The current perspective is that the sequence of

X-statements generates the trace back, and *if* another X-statement

(identifying the next 'pattern-unit') comes along that replaces a

previous label, then it is the job of the STIL writer to interprete

the labels properly.

Jason raised a concern about ambiguous labels - what happens if a

procedure calls the same procedure multiple times, but doesn't have

sufficient labels present? (for example):

With the X statements above, the specific call to LU is ambiguous; a

failure in EITHER call to LU generates the same label 46:MU:LU.

The fix to this ambiguity is to provide additional labels in

MU. Specifically, the lowest level function call that contains an

X-statement ought to have defined an unambiguous set of X statements

in the higher level calls in order to support sufficient resolution of

the failure for the tool performing diagnosis. This does not mean, for

instance, that the constructs above are incorrect *if* the tool

performing the diagnosis can accomplish it's job based on the offset

from LU (and doesn't need to have an unambiguous path to LU). However,

if it needs an unambiguous path to differentiate the multiple calls,

then it is the job of the STIL writer (correlating with the

requirements of the diagnosis operation) to provide that path

sufficient for diagnosis.

Tony identified that this limitation in the interpretation of the fail

report is purposeful: this is not a general data-logging technique but

is intended to provide correlation only for the environment that put

the X-statements into the file in the first place. The alternative

solution of a stack-dump through the STIL constructs relies on uniform

handling of all STIL constructs by all environments, and that cannot

be expected.

If a Pattern contains no X-statements, then the fail data may be

reported by cycle-offset from the start of the Pattern. Some

discussion about the X-reference to use in this situation; the current

proposal uses the name of the pattern. It was suggested and generally

agreed in the meeting to use the keyword Pattern here instead; as a

STIL reserved word the occurrence of this word is limited and cannot

conflict, for instance, with X-statement identifiers that happen to be

the same as the Pattern name. Tony [AI1] to provide the keyword

Pattern in this statement for this purpose.

Jason identified that a fail report will likely contain multiple

entries for the same X-ref, but different signals. For example:

    46:LU SO1 34 56 103;

    46:LU SO2 124 230;

This provides a very concise representation of failures across one

scan operation, for example. The concern raised in the last meeting

about data redundancy and data volume appears to be addressed at the

moment with the option to put multiple cycle references in one

statement.

3. Fails collected

Presented one perspective of using X-statements to identify range of

patterns run.

Doug raised a question about whether the signals being collected need

to be identified as well; it's possible that some outputs may be

turned-off for data collection (due, for instance, to swamping the

data with all fails from these outputs).

Peter raised the perspective that the 'range' needs to be applied in

the diagnosis environment through a different mechanism, (Greg's

perspective: it's a Start and Stop range on the patterns being fed

back to the diagnosis environment...maybe not a Start...). Providing a

range as part of the fail data is not a sufficient mechanism to

identify the consequence of this data for diagnostic consumption.

This started a discussion about pattern-modifications in general; the

resolution of the fails-collected range was tabled for a subsequent

meeting (with Tom B. to be in attendance).

4: Dumping all data

Some alternative strategies were presented: the Substitute operator,

"measuring-X-but-actually-detecting", or special data-logging constructs.

However, as in all good working group meetings, additional syntax was

proposed to cover this behavior. The extension to the current syntax

is to allow multiple measured-state values to be returned as part of

the fail statement, for instance:

     46:LU SO1 34 HHHLHLHL 200 LLLLLHLHLH;

The definition of multiple values is that each subsequent value

represents a single increment to the preceding cycle-offset value.

Currently, this *requires* a leading cycle-offset value which means

that dumping-all may result in a required cycle-offset of '0' (not a

problem, just to be noted):

     46 SO1 0 HLLLHHLH... ;