Phone Conference P1450.1 Working Doc Subgroup
Thurs August 15, 10:00 am PDT

Attendees:
Peter Wohl
Greg Maston
Tony Taylor
Jim Teisher
Jason Doege

Documents
p1450.1 D14 draft 8/1.
D14 review-resolution document 8/6.

Agenda
Starting with the agenda mailed by Tony:

agenda for meeting:
- Review clause 10 intro
- Review clause 10 Variables syntax
- For clause 10, review JT's ideas/proposal on variable usage
- Discuss Jason/Greg's findings wrt pattern merging
- Discuss plans for wg meeting at ITC

ITC
Tony getting a room for Monday 9-whole day.
Concept of having a general STIL status meeting starting at 4:30 -
5:30. Slips in between tutorials and start of special evening
panels. Greg thinks this is a good idea.

Clause 10
Tony made changes to the document per last meeting. Opened discussion
about the Usage statement.

Jim raised the issue of referencing variables; Tony identified the
Variables statement in the PatternBurst.

There are at least two contexts of variable usage - control-flow
related and "other".

Greg talked through use of variables in the ScanStructures block,
which is a "non-test" application of variables.

Discussion that the current "list of values" is not easily
interpreted. Proposal to reduce the Usage statement to test or
non-test only.

Based on this discussion, Tony is concerned that the last paragraph of
the intro to clause 10 might be too restrictive as well, as it
indicates the primary application is for control flow which Greg calls
a "Test" use - but the use of variables in the ScanStructures is a
"non-test" use of variables.

Jason asked why do we need to identify the usage - why not just make
the STIL application process it?

Motion: (1) on Integer variables only, (2) reduce the Usage statement
to a single attribute called "Test". Discussion about whether "Test"
is the right term; haven't found a better term yet.

Variables intro
Review of paragraph 2. Brief discussion.

Pattern Merging discussions
Jason presented an overview of the discussions between Jason and
Greg. Jason identified the load-capture-unload concerns, Greg is to
present how current mechanism can support this behavior (scan merging
as currently defined in dot-zero, section 5.5.1).

Discussed the perspective of spliting patterns during merge processes
and identifying periods of 'undefined' behavior. Presented the use of
the BreakPoint to specify locations in procedures and patterns where a
"gap of time" can be inserted.

Still discussing how to establish synchronism between patterns or to
resynchronize patterns.

Discussion about 'chopping up' a pattern and 'interleaving' it with
other parts of the pattern -- eg, merging the load with another
unload.

Identified a concern about order dependency between patterns; in this
case, don't write them unmerged.

Tony presented the concept of using signalvariables to pass the
previous unload into the next call, as a mechanism to "dynamically"
create merged patterns by applying the value of the signalvariable
during the next load. Advantage here is that the unload-data,
technically part of this last pattern, remains as part of this pattern
rather than appearing as part of the next pattern (it appears because
it's passed through a signalvariable).

Some discussion about sharing pins on simultanious (parallel)
patterns.

Greg to add BreakPoint handling to the LockStep definitions.

Reordering: two cores executing in parallel, talked about reordering
scan patterns to maximize overlap. Is this part of the standard or an
external operation?

Peter identified that even "reorderable" patterns may have
dependencies depending on how the patterns have been interpreted.
Even identifying the partitions of what a pattern is, IS a
tool-dependent interpretation.

Greg raised concern that the definition of a Pattern in dot0 is as a
single executable unit. Attempting to redefine a STIL Pattern as
partitionable (and the boundaries of the partitions) is incompatible
with the dot0 definition. One proposal that would allow reordering
would be to define a usage model that enforces generating patterns in
the smallest indivisable, independent units, and using the
PatternBurst constructs to identify sequencing opportunities for these
multiple Pattern blocks. For example, ATPG tools could write out each
separate full-basic-scan "pattern" (load-capture-unload) sequence as a
separate Pattern block, and using the PatternBurst PatSet construct,
listing all these Pattern blocks, would identify that each of these
STIL Pattern blocks could be executed in any arbitrary sequence.

This notion was generally accepted, but requires a mechanism to
support 'dynamic merging' between two patterns that are expected to
run in "parallel" but have a very specific, deferred start-point for
the second pattern: it starts (with it's load) during the final unload
sequence of the first pattern. Identifying this location is not
straightforward.

Greg and Tony refined constructs identified here off-line; Greg to
write-up.

Meeting adjourned at 11:30 am PDT.