Phone Conference P1450.1 Working Doc Subgroup

Thurs July 17, 10:00 am PDT

 

Attendees:

Bruce Kaufmann

Greg Maston (scribe)

Tony Taylor (chair)

Jason Doege

Doug Sprague

Thomas Bartenstein

 

Documents

 

   http://grouper.ieee.org/groups/1450/dot1/p1450.1-D16-review-resolution.pdf  (open issues)

   proposal from Tony wrt fail feedback - attached to end of this doc

 

Agenda

 

Fail Feedback Review


Meeting discussion

 

Fail Feedback Review

 

1.   Basic fail statement:

 

 - The proposed syntax was reviewed; format is very similar to what

is used by ATPG tools today.

 

 - Some discussion about the term "Pattern unit" insued. Much more

discussion about this below.

 

2.   Context of this data; the PatternFailReport {} block:

 

 - Current proposal has this block inside the Pattern block. It was

identified that this was incomplete; multiple executions of the same

Pattern block from different PatternBursts could result in different

failures; need more context information.

 

 - Tony [AI1] to move the PatternFailReport to a top-level block, and

to add sufficient referencing to bursts and execs to establish which

execution of this Pattern is being reported here.

 

- New issue: Concern was voiced about nesting of trace information

under the fail statement. This information (if present) inside a

repetitive failure across a set of signals or a scan chain output

could make the report data full of redundent information. A request

was made (no syntax proposed) to 'reverse' the positioning of this

data, as either some sort of hierarchical construct, or as a set of

'attributes' that persist across the next set of failures until

changed or identified that they end. This was left as [AI2] to Tony to

define.

 

- One question arose: is this information specifying a template format

for the report, or actual data format? The intent of this definition

is to specify the data format, not a template that identifies how this

information is to be formatted.

 

- This raised the next point: if this is the data format, and there

are options to the information in this format, what risk is there in

creating subformats of this data as different tools require/expect

different data? Are all the options necessary - can some be

eliminated, or are there situations where this "optional" data is

necessary and other situations where it has no meaning? Answer: the

expectation here is that a tool will support all the constructs here

(so there are no subformats), but if a construct is not used/necessary

then the tool will not apply that information, and if the data is

incomplete (ie, a failure traces down to a loop but which loop failed

is not identified) then the tool will have to report back that the

failed data was not sufficiently complete.

 

- This brought the discussion slowly back around to the first construct

of the failed statement information - the "Pattern Unit Number" and

all of it's intentions. The current proposal identified that this

"number" was intended to be cross-referenced back to a pattern label

of fixed structure containing this number, which raised the issue that

not all tools use the same labels (and in fact one generator uses

labels and another uses Annotations to hold this information), and

using fixed labeling constructs is not a robust mechanism for

cross-referencing.

 

This brought up some discussion of using the Xref statement, already

defined in dot1, for this purpose. By using a new construct for this

function, existing behaviors can continue and new behaviors are

constrained to the semantics defined. Tony [AI3] to define use of Xref

here.

 

Then the placement of the Xref statement was raised. The issue

at hand is that most ATPG contexts identify the start of a new

test-unit as the point where the scan-in data starts to be applied,

but require failure information to be identified against the PRIOR

test-unit identifier even though it's occurring within this new

test-unit because of the overlapping of the unload and load

operations. The problem is that these test-units ARE overlapping,

and it is desired to identify both the start of the next test-unit AND

THE END OF THE PREVIOUS TEST-UNIT. The end-statement was called

X-prime in this discussion, and has only the semantic that any

subsequent failures after this point get identified to the last X-ref

statement whereas any failures before this statement get tagged to

X-ref statement before this one. Tony to contemplate this issue and

consider a syntax for the x-ref-end statement [AI4].

 

At this time a discussion of the "cell#" started. It was identified

that the notion of the cell#, as an 'index' was also not uniform;

during test execution it is affected by scan-state bits that have been

pulled outside of the Shift block, or additional vectors before or

after the primary scanning operation. But the Working Group ran out of

time to complete this discussion, so it is left for the next meeting.

 

Meeting adjourned at 11:34 PDT.

 


Next meeting

Next phone meeting July 31.

 

AIs

new

[AI1] Tony - PatternFailReport top-level block with burst refs.

[AI2] Tony - failure-location information as persistent attribute.
[AI3] Tony - Xref application for 'pattern unit' identifier.
[AI4] Tony - X-ref-end construct.
[AI5] All - consider the definition of the cell# construct.

 

old

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

[AI2] Tony - Work with Paul Reuter to see if any additional syntax or

interpretations are required to support the lock-step implementation as

currently being envisioned by the P1450.6 working group.


Fail Feedback Proposal by Tony:
Basic syntax (you will note its similarity to the format used by several commercial ATPG tools) -

PatternFailReport {
    ( pu#  sig_name  (cell#)  (< L | H | T >); )*
}

pu# = pattern unit number - This number is derived from labels provided within the pattern. i.e., pattern56: or "pattern56"
sig_name = name of a primary output or scan out signal
cell# = scan cell number. This parameter is required if the sig_name is a scan out signal
< L | H | T > = optional fail state. L, H, and T are the fail events as observed by the tester. This parameter is optional as in most cases it is sufficient to know that this signal does not match the expect state as defined in the pattern.

Examples -
    13 PO1;
    29 PO5;
    42 SO1 19;
    59 PO2 H;

The above syntax can be provided as a stand alone file, or in the context of a full STIL pattern. The full context must be known (by the tool processing the data) in order to resolve signal names.

STIL 1.0 { Design Dxx; }
PatternExex {
    Timing TIMINGNAME;
    PatternBurst BURSTNAME;
}
PatternBurst {
    Pattern PATNAME;
}
Pattern PATNAME {
    PatternFailReport { ... }
}

Additional attribute statements that can be added to the basic syntax are shown below. This additional syntax allows to:
1. support multiple measures on a signal within a pattern unit
2. support loops within a pattern, macro, or procedure
3. identify the waveform table that defines the failing waveform

PatternFailReport {
    ( pu# sig_name (cell#) (< L | H | T >) {
        Loop loop#;
        Measure meas#;
        Macro macro-name;
        Procedure proc-name;
    }  // end pu#
}  // end PatternFailReport

Example 1: failure on second measure on signal PO1 in pattern unit 56 -
    56 PO1 { Measure 2; }

Example 2: failure in macro MAC on the 99th time through a loop in pattern unit 82-
    82 PO1 { Loop 99; Macro MAC; }

Example 3: failure is in the 14th loop within procedure PROC which is called from pattern unit 35
    35 PO1 { Procedure PROC; Loop 14; }

Example 4: failure is on loop 66 of pattern unit 49, which calls macro MAC, which fails on loop 19, on second compare of PO1
    49 PO1 { Loop 66; Macro MAC; Loop 19; Measure 2; }

Example 5: a complex example
the pattern is as follows:
"pattern 33": Loop 100 {
        Call PROC { ... }  // fail on loop 5
        Call ANOTHERPROC { ...}
    } // end Loop
Procedures { PROC {
    Loop 100 {
        Macro MAC { ... }   // fail on loop 16
        Macro ANOTHERMAC { ... }
    } // end Loop
MacroDefs { MAC {
    Loop 100 {
        V { PO1 = H; }
        V { PO1 = L; }  // fail on loop 6
   } // end Loop

the fail record is:
    33 PO1 { Loop 5; Procedure PROC; Loop 16; Macro MAC; Loop 6; Measure 2; }