Phone Conference P1450

Meeting discussion

IEEE meeting clearances
Nothing under discussion or presentation for this meeting was identified as being proprietary or restricted.

1: Balloting
--------------

Ballot finally closed after being extended for 10 days due to non-responders. Achieved all IEEE criteria for successful first ballot
pass but need to do negative ballot and comment resolution (process that is starting now).

ABSTAIN	2
YES	33
NO	6
RETURNS	85.4%
APPROVE	84.6%

2: Process question
-------------------
Bruce asked what is the process. Response is: we do review of all comments now, to our knowledge there is not a time limit to this
process as long as we make progress. At the end of this process we need to do a "recirculation ballot" to review any technical changes to
the draft, to the same balloting group, during which the balloting group has the ability to change their original response (and submit
more comments). We again resolve negative ballots, but in the recirculation process we are allowed to "agree to disagree" with
negative balloters if the issues are not resolvable (for instance, disagreements about scope of the effort may be acceptable negative
issues). Depending on whether technical changes are made to the document at this point, a recirculation may be necessary again
(changes for editorial comments do not require recirculation). The number of re-circulations is unlimited but realistically too many
iterations indicate lack of a standard.

DS-1 : hex compaction of fail data
----
Review of pg 65,66 of D-19, line 1043 - string of H and L's. Peter made the proposal to support the use of the hex compaction construct,
as defined in dot-zero. Use \h to change to hex, also support \r. \d doesn't make sense in this context (there is not an explicit length
on this data), so don't recommend the use of \d.

The WG raised no objections to this proposal.

Subsequent discussion identified that the characters being used in this context (H,L,T) are not truly WFCs, they are fail-events. Greg
identified that the wfc-list resolution process does not rely on the WFCs being defined, as the process is two-step - the first part
expands a wfc_list into a set of characters, and the second step (for patterns) resolves each character against a signal/WFT/waveform
context. The second step is not used in the PatternFailReport.

This identified that in order to use the dot-zero Base for a sigref in this context, the Base must specify at least one and possibly all H,
L, and T "wfcs" (depending on how many of these states actually failed). This has an *implication* that H, L, and T might be good WFCs
to use on the Pattern side of things as well, if the same sigref is used in both the PatternFailReport and the Pattern. While this
perspective is true, a recommendation to use explicit mapping with \hHLT (or whatever fail states are required), and \w to switch to
individual character constructs in the context of the PatternFailReport was seen to be the best way to avoid any perspective
that the PatternFailReport constructs were impacting Pattern constructs.

DS-2 : identify/classify 'type' of fail in PatternFailReport
----
The request is to support some construct of defining addition information that indicates more information about the context of the
failure.

Concern is that "classification" of failures is not uniformly defined in the industry; different companies with different testing strategies
and analysis flows classify things differently. Defining a keyword without semantic intent is useless.

Peter raised the following example of reporting failures from the same pattern with different voltages and temperatures. The desire is to log
these conditions as part of the fail data. The problem is that we don't know the entire set of conditions, or even the values to
apply... the set of conditions is too open-ended and dependent on each application.

The proposal from the WG is to recommend the use of UserKeywords or Annotations to address this functionality. Doug, as submitted of this
issue, accepted this, but this issue was raised another time as well (below).

It was also pointed out that the X statement itself is a label that can have meaning to a consumer of pattern fail data. The X label is in every fail record and a user/tool convention could be used to interpret fails according to this label. An example given was for memory fails.

DM-9 : parallel pat - delay start of a pattern (to allow patterns to end together)
----
The response of the WG is: it is valid to delay the start, but there are no special constructs to support a mechanism to delay a pattern
application. The recommendation of the WG is that if a user wants to delay the start of a pattern, they define and insert a
padding/synchronization pattern to define that delay.

Subsequent discussion in the WG identified that for all applications that the WG was familiar with, synchronizing to the START of an
operation was key functionality; no applications where synchronizing from the END of an operation is known.

DM-10 : question about Wait
------
Dan presented on the use of Wait in Figure 1, and raised the question about whether each of the blocks (patlist,parallelpatlist, patset)
*should* start executing before another one of the blocks completed.

Several WG members identified the perspective that each of these blocks operate as an independent container of operation, and that *if*
things are meant to operate in parallel then they need to be identified by common containers (using hierarchical patternbursts as
necessary with ParallelPatLists as necessary).

This perspective eliminates the need for Wait, for by definition, each container does a Wait for the last pattern to complete.

This led to a discussion about Fixed. As currently defined, Fixed is placed on a Pattern but is defined to affect signals outside of the
Pattern (in fact, not used by any of the Patterns of this block). This functionality can be totally addressed by defining a 1-line Pattern
that contains a Fix statement for this signals, and referencing this Pattern in the block. This is seen to be more direct and less
ambiguous solution without requiring additional syntax constructs.

Proposal from Dan is to remove the Wait and Fixed constructs in the PatternBurst. The WG accepted this conclusion. Tony and Dan to review
implementing this.

DB-4
----
This issue is the same as DS-2; closed as above, but need acceptance by this reviewer.

GM-5
----
Simple issue, need to change * to + in the ActiveScanChain syntax description.

DM-11 : what happens w/no extend in the PatternBurst?
-----
The WG started a discussion about what does happen. This led to the conclusion that the text on pg. 37, under 'Extend' needs to be
elaborated. The paragraph on Extend needs to either elaborate on definition of 'tile' or use different terminology. Also need to
clarify the behavior between extend, breakpoint application, and pattern aligning. For instance: what happens for two parallel patterns
that both have Extend *and* a BreakPoint with Vectors, but don't align on vector boundaries, and each has a large different prime number for
the period? does the test run until the first time both periods coincide at the multiple of these two prime numbers?

DB-1 : what does a tester have to do to be compliant w/.1
----
Tony identified a new proposed annex O. Greg identified that there is good information here, but that any use of the term "subset" will
raise major red flags and scope issues at the IEEE level, and must be avoided at all costs.

Greg provided the following response for review:

To be compliant with a standard, you have to apply all parts of that standard that make sense in your application. There are *always* parts
of a standard that do not make sense for a specific application, for instance a hardware circuit description may not use part of the
defined circuitry because the functionality supported by that part of the circuitry is not part of the current design.

Likewise, not all parts of dot-one will be used or usable in all applications. The identification of unusable parts is the
responsibility of the application.

DM-14 : scanlength optional
-----
Some members reviewed and accepted this proposal, but other members of the WG raised concerns. This was tabled for additional review.

DM-22 : use of term 'namespace'
-----
This issue was discussed; the WG was comfortable with the current terminology and "something better" was not identified. The submitters
proposal of "object" is seen to carry an implementation context with it. Resolution of the WG is don't change this.

DM-22
-----
Tony asked the WG to review the first paragraph in subclause 6.4, meant to address this issue.

Next Actions
------------
The Expression Review Subgroup organized a meeting for Wed Mar 10, 9am PST, same access code, to discuss expressions.

Meeting adjourned at 11:39 pm PST.