Attendees:

Greg Maston (chair & scribe)
John Cosley
Bruce Kaufmann
Daniel Fan
Jose Santiago
Doug Sprague
Ken Posse (at end)

The meeting this week is to focus on dot3 and what is needed to get it going again. Although dot3 has been dormant for more that a year, I believe that it should not take much to bring it to completion ... unless new issues have arisen ... a strong possibility. At a minimum, we need to make a pass through to make it compliant with the latest dot1.

Discussion:

Dot1 status
8 affirmatives to date. One negative balloter is now a YES but doesn't remember how to vote and won't hassle with the system. Another NO voter responded that the current proposal is much better but would hold his NO vote - don't know if this will be associated with additional comments or not. Still, we have sufficient positive votes to move ahead with this effort.

Dot3
Greg identified two areas of concern for him in the current proposal. These are:
(1) Memory checking. There is little definitive process on how to check memory, and this has been highlighted as a problem with one early user of this draft. Greg has an augmented memory count / memory checking spec that he will present to the group next week.
(2) dynamic configuration support. Based on discussions with several users, there is concern about how to define TRCs around highly configurable testers. The tester rules are sufficiently flexible that it's possible to define just about anything - and validate just about nothing.

Dan presented one aspect of this problem with a configurable tester that has 20 channels (max) and runs at 3 GHz (max), but can do neither at the same time. When using 20 channels it runs at 400 MHz, when running at 3 GHz it has 5 channels available. And there are a slew of configurations in between. If each configuration of the tester is defined as a separate block, we have "TRC file explosion". And on the user end: the rules-checking has to report against each configuration, when in fact only one configuration will be used (or perhaps usable) for the STIL test to begin with. All the errors for unusable configurations just makes noise for the user, *if* there's at least one configuration that is functional (and note, TRC flows often do not report success, only failures).

If this information is stored in it's most configurable representation, how do we do rules-checks against this? For instance,
if there's a trade-off between cycle time and number of signals, and a test program violates this trade-off space, is the error reported as cycle time too short, or number of signals too large? (and no, it's not both). How do we provide for a TRC environment that returns meaningful information in this context?

Jose indicated that perhaps there's an initial pass to validate whether there's any possible use of this tester (Greg's words: perhaps
to determine configuration), and a subsequent pass to robustly check this configuration. John inquired perhaps there's a formula or a table to establish some basic configuration behavior to do rules checks against.

Jose asked if there were any old issues with the spec that need to be reviewed. Greg took an Action Item to review old status, although he thinks (naively) the last draft was meant to address any previous issues.

Bruce took an Action Item to consider his tester in the context of the current draft proposal.

Greg took an Action Item to get his extended memory counting spec into this Working Group for the next meeting.
 

Next meeting

Date: Next meeting Thursday, Apr 21
Time: 10:00 to 11:30 Pacific
Dial-in#: 888-635-9997
Participant code: 539645

Action Items:

AI-1: Greg -  provide spec for "extended memory counting"

AI-2: Bruce - consider his tester in the context of the current draft proposal