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/minutes-2003-07-03.html (minutes of last meeting)
http://grouper.ieee.org/groups/1450/private/p1450.1-D16.pdf (latest working draft)
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.
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; }