Reviewed status from last meeting. Concern about one balloter on this
construct which requested a different change (moving this construct
under scanstructures). That request is not satisfied, need to contact
reviewer and make sure this is OK. Also removed the capability to
reference a scanchain name in cellgroups, concern here about
uni-directionality between scanstructures and cellgroups, would
*expect* a more bi-directional context and there are no current
requests to support direct scanchain references from here - so
removing all cross-reference capability.

Timing Expressions

Issue raised in the last couple of days about using time expressions
in dot-6. Time expressions are defined in dot-3 at this time. Desire
to move the definitions in dot-3 into dot-1 to simplify cross-spec
requirements.

Rohit identified that the constructs present seem to be not in
alignment with the dot-6 application. The concern is that the current
definitions for @@, etc., reference event sequences. The dot-6 context
does not reference 'events' directly. The intent of @@ is to reference
"the current time" and this might need to be clarified.

Additional requirements, context of dot-6 application:
- timing associated with 'leading or trailing event'
- additional capability of 'numbered' leading or trailing event
- Concept of self-edge and reference-edge, with timing being a
reference between the two.

Annex F

Issue raised by Rohit that the example in Annex F is that it is
identical to the example in dot-6. Rohit's request is to modify this
example to a context separate from this context. Working Group agrees
to modify this example in order to address this concern. The primary
objection is that the example has what appears to be cores (although
they are called modules) and has a serially connected scan chain. The
example should be changed to demonstrate AllowInterleave through the
use of shared primary In/Out signals.

DAC face-to-face

DAC meeting has been cancelled as Peter is the only one committed to
attending DAC and the focus is now on working through all the issues
discussed at the VTS face-to-face last week.

Pattern Fail Report

The VTS meeting clarified that fail-report label-reference sets
INCLUDE procedure/macro names in order to unambiguously reference
statements.

Tony and Doug discussed a notion about higher levels of
compaction. Fail records are either 0,1 or hex-encoded. Proposal for a
base-64 using all ascii characters. Greg identified that this has been
previously discussed, and was dropped because gzip compression exceeds
any ascii-level compression options. Doug indicated a desire to have
an 'unencrypted but compressed' option, however no other members
advocated for this. Concept was once again dropped.

Request from Bruce to enhance x-labels to tag end of shift
operations. Some discussion about the need for this and the behavior
of different tools, but in the end Bruce got an Action Item to receive
the current pattern fail section and augment for several issues,
including this one.

Plans for ballot re-circulation

Rohit identified that P1500 is pushing for a coordinated dot-6
reciculation in a month and a half. Tony indicated hesitation that
P1450.1 would be ready by then.