Attendees:

Tony Taylor (chair)
Greg Maston (scribe)
Dave Dowding (at start)
Bruce Kaufmann
Jason Doege
John Cosley
Jose Santiago

Action Items from before:
AI-1: Greg -  update spec for "extended memory counting"
AI-2: Bruce - create TRC for the Teseda tester using the D09 draft
AI-3: Tony - address issues listed in "Dot3", above
AI-4: Tony - send email to NesCom re: the negative ballots
AI-5: Tony - do something about the dot3 PAR expiration
AI-6: Tony - solicit pin-file formats
AI-7: Tony - re-vamp the sub-set proposal and take it to the UG

Discussion:

Dot1 status
- no vote causing heartburn. (ai-4, done)

Dot3 status
    extension through '06 (ai-5, done)

AI-1:  update spec for "extended memory counting"

    Greg is still working, AI-1 still open

AI-2: create TRC for the Teseda tester using the D09 draft
Bruce had several email discussions. One proposal was copied around to the dot-3 group, to support a "|" option to support defining multiple blocks with selection or identification of only 1 of those blocks in order to pass the constraint checks.

Some discussion followed about the issues with these choices - for instance, failing a block when there were other blocks available may not be informative (because a "pass" is established when at least one block passes, even though others may fail). So errors about failing blocks may not be pertinent until it's known that ALL blocks fail - and once all blocks fail, you probably want to generate errors for each block so the user can review what's the closest possible match (which may not be the block with the fewest failures).

AI-3: address issues listed in "Dot3" (5/19 minutest)

on-going

AI-6: solicit pin-file formats

Jason volunteered to contact Inovus for their pin-map format.

AI-7: re-vamp the sub-set proposal and take it to the UG

done.
 

Discussion about "intent" of a TRC file
Jason raised some questions about maintaining test intent. For instance, when, in a test program, is the specified timing critical or not? For example, consider scan behavior and shift timing, vs. path delay launch-capture timing: the shift timing is flexible with no loss of test functionality, but the path delay timing may not be (additionally, it may be only one particular event-pair in this operation that is critical...). Test rules might not be violated because of shift timing, if the shift timing is modified a bit, but the path delay timing shouldn't be so freely toyed with.

The discussion wandered around whether this was a specification of the test program - or even part of the device spec - or was this part of the constraints problem? Jose proposed that the tester definition file defines maximums, but that a subsequent operation maps onto tester resources.

Tony speculated on the need for more application-options to identify the purpose of various TRC blocks, to support a "maximum values" block vs. a block that is intended to check resource allocations.

No specific actions were indentified with regard to this issue, however, it is expected that this will be examined further in the context of specific TRC files that are being created.

 

Next meeting

Date: Next meeting Thursday, June 16
Time: 10:00 to 11:30 Pacific
Dial-in: 888-635-9997
Participant code: 677459

Action Items:

AI-1: Greg -  update spec for "extended memory counting"
AI-2: Bruce - create TRC for the Teseda tester using the D09 draft
AI-3: Jason talk to Inovus about pin mapping support/format
AI-4: Tony make dot3 consistent to current expressions
AI-5: Tony keywords relax, check xrefs to other docs