minutes-2002-06-21

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

Signal Types

This is a discussion that is carried over from the prior meeting and that evolved out of a proposal from Greg to somehow identify the types of the signals and connect them to the rules for waveform checks. Types being things like clock, data, scan which are more meaningful in design than in the ATE environment.
After considerable discussion on the issue we came to several conclusions which were unanimous amongst those present. First that it is not a good idea to determine the signal types by implication from the waveform definitions in the test data (as proposed in Table 5).
The second avenue we explored was to add new attributes to the Signals and SignalGroups block and tie them to specific TRC rules. This solves the first problem. But, in reality, it is not a workable solution since most test program generation is not going to have the foresight to prepare things to be convenient for TRC checking.
The third (and final) avenue was to drop the whole idea - remove table 5, and remove the attributes from the WaveformChar and WaveformDesc statements. A TRC checker is to be responsible for finding a match to all rules in the appropriate TRC-Waveform blocks. We also realized that the <tag> facility that was for specifying "tester targetting" can also be used for "TRC targetting".
Action: Tony to remove table 5 and the type attributes.

Draft doc work

The above issue is the only outstanding syntax issue. So, after making this change, we will freeze D10 and move to D11 to clean up all the descriptive information.

Ballot issues

We were not sure how long IEEE allows between ballot group formation and submittal of the ballot draft. Greg or Tony will find out. In any case we put off any decision to begin the ballot process until the next phone meeting.

Dan's TRC file

Dan's TRC for the D4032, having gone through several review cycles, is now getting close to complete. Tony identified a couple of areas of confusion. They had to do with the use of spec variables to provide flexibility. The TRC needs to be clearer about ATE limits vs. user provided input - i.e., things like "LONGEST_SCAN_SHIFT" and NUM_Scan_Load_Unload". Where do they come from and how are they to be used. Another question is how checks get made on expression results - i.e., "NUM_800BPS_PER_D4032". Seems like we need an Assert statement in the SystemChar block.

TRC files for other ATEs

We ran out of time to discuss this topic, other than to agree that we need to get other ATE vendors to create TRC files. We will bring this topic to the stilusers meeting on Feb 9.

Meeting adjourned 11:35 Pacific time