Phone Conference P1450.3 Working Group

Thursday, Feb 2, 2005 -  10:00-11:30 Pacific Time




Attendees:

Tony Taylor

Greg Maston
Daniel Fan
John Cosley
Doug Sprague

Paul Reuter

Dave Gallegher

 

Docs:

 

    http://grouper.ieee.org/groups/1450/private/1450.3-D10.pdf

    www.stilusers.org/plone/public/trcfiles/Credence-D4032.trc.stil

 

Agenda:

 

1. Review proposal on signal types.
 
2. Are we ready to freeze the syntax and focus on descriptive material?
 
3. Time frame and plans for ballot submission.
 
4. Continue review of Dan's document.
 
5. Ideas to get other ATE vendors to work up TRC descriptions.

 


Discussion:

 

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

 


Next meeting

Date: Next meeting Thursday, Feb 16
Time: 10:00 to 11:30 Pacific time


Action Items:

AI-1: Tony - make syntax changes as indicated

AI-2: Dan - update TRC file (one more time)

AI-3: Tony - prepare D11 after completing the remaining syntax changes