Phone Conference P1450.1 Working Doc Subgroup
Thurs June 21, 10:00 am PDT
---------------------------------------------
Attendees:
----------
Doug Sprague
Peter Wohl
Tony Taylor
Greg Maston

Agenda
------
Agreed to by consensus:
1) Review Tony's signal_mapping document (referenced separately).

Documents discussed:
--------------------
[1] p1450.1 proposal, dated May 22, 2001, distributed by Greg.
[2] Tony's Variable_doc (and expression-handling),PDF, separate link.
[3] Peter and Greg's "diagnostic feedback in non-failing environment",
email attached at end of these minutes.

Tony's Signal Doc
-----------------
Started reviewing this document at section 4, to talk through examples
in the document first (sections 4-6) and then discuss the expressions
and then discuss the issues.

First point raised by Tony, that the previous variable type "WFC" has
been renamed to "SignalVariable" here, because it reflects their
application more clearly - they behave just like Signals or
SignalGroups in handling WFC-lists, and are assigned only to Signals
and SignalGroups when used, etc. The group agreed with this name
change.

Example 4 presents a construct on bracketed-name referencing, where
lists of elements are individually referenced with an "integer
list". Greg raised a question about lack of "," in here, which was the
previous construct proposed to support this mechanism. The discussion
then moved to point 5 of [2], which is the notion to define a uniform
construction around the handling of "integer lists", and supporting
integer lists one way with a uniform set of operators. The discussion
included what type of operators are to be supported here, since the
bracketed construct currently supports "..". Decision was made to
define integer lists uniformly and support both commas and elipses as
operators in integer list constructs.

Discussed the additional construct of an empty-bracket reference
(e.g., sig1[]) to mean the default/declared index range, and rejected
it in favor of explicitness (fully specifying the range in all uses).

Discussed the use of "+" in the context of SignalVariables, as a
concat-style operation between the contents of these
variables. Decided to NOT allow this, and in fact to NOT allow any
operators for SignalVariables. Discussed adding another column to the
operator table, for SignalVariables(expressions), and indicating none
of these operators were defined for this type.

Discussed the issue of defining an explicit "boolean expression type",
to allow signalvariables to be compared to WFCs, without allowing true
logical oeprators (like &) in there. Decisions is to do this.

Issue list
----------
Peter requested to add issue #3 to this list: the Waveform event
CompareSubstitute, defined to support enhanced diagnostic return and
"known-good die" learning capability. Greg attached the issue to the
bottom of these minutes for subsequent review by the group.

Doug identified that he owes the group a write-up on the "merge()"
function, currently still open from last discussions on the BreakPoint
designation issue.

Doug identified that the Else construct needs to be added to the
current spec.

Tony talk through issue #2 of this signal_mapping doc. WFCMap on the
Signals causes conflict/problems when taking STIL from multiple
sources. Peter is concerned about putting the information in Timing
because the implication of this data is in the Procedures block and
the binding of timing information is at the PatternExec level which is
"farther away" than desired. Discussed how this block has moved from
the PatternBurst in previous changes. Discussed the previous
motivation of maintaining the Signals and SignalGroups identical to
facilitate an object-model definition, but one option is to allow
WFCMap only on the SignalGroups. No resolution of this issue was made
in this meeting.

Other Issues
------------
The next meeting is the regularly-scheduled Thursday meeting two weeks
(July 5). Tony will maintain this signal_mapping doc separate from the
spec for the next review, to remain focused on these issues.

Meeting was adjourned at 11:30 PDT

AIs
----------
AI[1] - Tony update signal_mapping doc with resolutions above.
Annex new: Support for Diagnostic Information Return in "non-failure"
Environments


===============================================
=== Peter and Greg's Diagnostic Extension Email
===============================================

This annex describes a usage scenario that combines several
capabilities defined in this standard to provide complete support for
returning tester information in a "non-failure" context, for
evaluation or review by CAD tools. While this example is oriented
around returning information for diagnostic applications, this
functionality is not constrained to this to application.  This
scenario can also be applied to the general notion of "learn-mode"
tester operation, where the test provides the stimulus only and the
response is "learned" by reporting the behavior from testing
known-good devices. Integration of the return values in this mode of
operation, into a new test program in this context is the
responsibility of the CAD environment interpreting this returned data.

To support the return of test values from a STIL test program, several
constructs need to be present in the program. This example assumes a
scenario where the desired return information is a subset of both the
set of signals in the design (that is, only one Signal needs to be
evaluated), and a subset of the test vector sequence (that is, there
is a specific region of the test where this information is
needed). This scenario presents the "worst-case" application of these
constructs; see the Note at the end for a discussion about the
consequences of generalizing these restrictions.

Step 1 - Identifying Signals

The set of signals that return response data are identified by
defining a new Waveform for those signals. This Waveform contains an
"S" or CompareSubstitute event for the region where the value needs to
be checked. Typically, the timing of the S event will coincide with
the timing for CompareLow and CompareHigh checks also defined (but may
not be used) for that Signal. For example, if the original waveforms
on Signal A1 were defined as:


 Timing {
   WaveformTable A {
     Period '20ns';
     Waveforms {
       A1 { 01X { '14ns' l/h/x; '18ns' X; }}
     }
   }
 }

Then the additional Waveform could be defined as follows:

 Timing {
   WaveformTable A {
     Period '20ns';
     Waveforms {
       A1 { 01XC { '14ns' l/h/x/s; '18ns' X; }}
     }
   }
 }

If the timing of the compare-low check does not match the timing of
the compare-high check, a decision must be made on how to define the
timing of the waveform containing the S event. Typically, the S event
would be defined in a waveform that defined the overlapping region of
both the low strobe and the high strobe, in order to return the
correct value if either of these states was detected during the test
execution.

Step 2 - Identifying Response Waveforms

There may be several Waveforms defined on a Signal that have the same or
similar characteristics to the Waveform containing the S event. To
support explicit designation of a desired WFC to represent a return
value from a waveform containing an S event, the WFCMap construct is
used to specify an "inverse mapping" relationship. This would be
specified for this context on Signal A1 as:

 Signals {
   A1 Out { WFMap { C -> 01X; } }
 }

Remember that the order of WFC references in the mapped output side
(the right or "to_wfc" side) is important: the first reference
represents the compare-low state, the second reference represents the
compare-high state, the third value represents the compare-unknown
state (which represents a test value that is not high, low, or changes
during the measurement interval), and the forth value represents the
compare-off (high-impedance) state, if the output supports this
operation and the tester can return this state during execution of the
test. 

If there are multiple Waveform definitions, each with S events for
this Signal, each different Waveform (with a unique WFC reference) can
specify a unique set of Waveform response mappings. This allows for
differentiation of the response data if desired or needed for
evaluation/review purposes.


Step 3 - Pattern Reference

The final step is to identify the desired pattern location where
response data is desired. This is indicated by the application of the
WFC that contains an S event, in the Pattern data. One example of this
is:

 Pattern diag_one {
   ...
   "Pattern17": Loop 200 { V { clk=P; A1=C; } }
   ...
 }

This will enable the response-return for all Vectors inside this
single Loop construct (in this example, for the 200 Vectors contained
in this Loop).


Step 4 - Tester Response Return

The return format for this information is tester-dependent, but a
recommended format using STIL constructs would be to return this data
following the diagnostic information return for failing data as shown
in Annex K. For example, the return data for this scenario could look
like:


 Signals {
   A1 Out { WFMap { C -> 01X; } Base Hex 01; }
 }
 PatternBurst feedback {
   PatList { diag_one; }
 }
 PatternExec {
   PatternBurst feedback;
 }
 Pattern diag_one {
   X "Pattern17";
   Loop Data { V { A1= 0000000000 0000000000 0000000000
                       01AAAAFFBA AAAFC44000; } }
 }

Note this is the complete returned data. The return environment mapped
the response data into a one-bit hex context (all device responses were
either high or low, so the X value was not used), and defined the
Base Hex for these two WFCs in the declaration of A1. The 50 hex
characters above define all 200 expanded WFC references for this
signal. 

The return environment also made use of the Loop Data construct to
return all these values under a single statement for this set of
Vectors. This construct is applicable in contexts where the set of
return vectors are adjacent (as was generated by the original Loop that
contained the 'C' WaveformChar), and provides for compact
representation of this information. 

...

Note:
While the normal operation of this facility is expected to be applied
for a limited set of signals, over a limited range of test vectors, it
is straightforward to generalize this behavior to all signals/all
vectors. By replacing all compare events across all Signals in all
WaveformTables with S values, all Vectors will see a "Substitute"
event for each output compare operation and will return detected event
behavior when this test is executed.


--------Spec changes to define these additions:

--- Signals: need to extend the WFCMap to support "reverse-mapping"
(actually "unmapping") behaviors... the context is whenever the
from_wfc is a single WFC reference and the to_wfc is more than one. I
will provide the explanation about the interpretation on the order of
the WFCs as part of this definition.

--- WaveformTables, actually table 10 of the dot0 spec (compare events)
  - define the S/s CompareSubstitute/CompareSubstituteWindow events
  - define semantics around mulitple S events in one waveform: either
this is not allowed (only one 's' in a waveform) or all events must
be to the same value or they generate the unknown-return value... no
support for reverse-mapping of multibit waveforms...

-- information missing from here, that would be part of the semantics
   defined around the 's' event: if the WFCMap is not specified for a
   WFC that contains an 's' event, then the return
   information does not attempt to do any mapping to WFC
   representation, but returns \e events in the Vectors... (which is a
   really big set of return info, but is a reasonable default if no
   WFCMap was specified...)

-- add the annex above as Yet Another Annex...