Phone Conference P1450.3 Working Doc Subgroup
Fri Dec 14, 2001, 1:15 to 3:00pm  PST
Minutes ammended 12/18/2001
Tony Taylor
Frances Miller
Bill Chown
Dan Fan
Jason Doege
Greg Maston
Jose Santiago

1. WFCMap block
2. NameChecks block
3. Semantic definitions (and plans for completion thereof)
4. Other issues

Clause 18, NameChecks -
1. Group decided that NameChecks should be moved to be a top level block within Environment->TRC. It was previously located inside the PatternCharacteristics block.

2. The name checking is done by specifying a regular expression in the CharacterContent statement. Tony agreed to research a document that can be referenced by this standard that defines a "regular expression".

3. The group decided that it is not a requirement of the standard to define a mapping operation for names that don't meet the check rules. Obviously this could easily be done by a substitute operation in the regular expression, however this is a function of a tester-targetting-tool (see fig 1 on page 3).

4. We discussed the relation between Environment->TRC->NameCheck and Environment->NameMaps. The NameMap is a general syntax that allows the definition of any name transformation into some other environment. A NameMap block may be used to define the tester channel assignment, or possibly to define a name mapping that a tester-targeting tool performed due to name-check violations.

5. The italicized comments in the NameCheck blocks can now be removed. All issues have been discussed and Greg's suggestions agreed to.

Clause 9, WFCMap -
1. The group had a change of heart from the last meeting. After pondering this issue for the last month, the group now feels that since this is so close to the tester that the actual mapping information should be put inside a Pragma block and expressed in the native format of the tester. Since not all interested parties were not present at this meeting, we decided to make the final decision on removeal of WFCMap at the next meeting. NOTE: If anyone feel strongly about this they should plan to attend the next meeting, or at least notify the working group.

2. The Resource statement on each pattern vector should be maintained in the standard and would contain lables or addresses that point to tester memory.

Formatting issue - There was confusion as to which blocks are TRC blocks and which blocks (like Environment ->NameMaps and Pattern->Resource) are outside of the TRC block. Tony agreed to make the document more clear in this regard.

PatternCharacteristics - There is a violent debate raging as to the best home for this block. The possible places for it to reside and the reasons for each home are defined below. The reson for the debate is because there are three different contexts for use of this data: 1) the definition of tester rules for a particular model ATE, 2) as documentation within a Pattern or Burst as to the characteristics of the pattern data itself, and 3) as information about the pattern or burst necessary for integration or re-use of a pattern or burst.

1450.1 - Since this data is to be referenced by both 1450.3 and 1450.6, placing it in 1450.1 would make it more commonly available.

1450.3 -  The PatternCharacteristics are part of a complete set of statements that define signals, periods, waveforms, patterns. It is important that this set of things be considered together and remain consistent. Hence maintaining this block in one standard is desirable. Note: It is still possible to define that this block can be re-used within another context, even if it is defined in the 1450.3 standard document.

1450.6 - The CTL application cannot work effectively without this information. Hence, it is desirable to have this definition within the CTL standard extension.

Jason Doege - response to Action items:
In a previous conference call, I was left with two deliverables:

1) How does IEEE 1149.1 assign device ID codes to various
   manufacturers. This was for the purposes of determining how
   we might control usage of ATE identifiers to prevent confusion.
   I.E. LTX is used to refer to LTX ATE and no other.

It turns out that 1149.1 defers to JEDEC and JEDEC assigns device
ID codes and keeps the list. A company must apply to JEDEC for an
ID code:

2) Provide example of how Inovys uses STILish pin assignments

We use a top level construct called PinList to perform pin
assignments. It probably ought to occur after Signals:

PinList "PL1" {
 A0 "1"(  1);
 A1 "2"(  2);
 A2 "3"(  3);
 A3 "7"(  4);
 A4 "8"(  5);
 A5 "9"(  6);
 VDD ( PS);
 WAT_ "10"(   7);
 WT_ "11"(  8);

The format is signal_name, package_pin_name, tester_channel or,
in the case of a power supply, supply_signal_name, tester_power_supply

Open Action Items:
11/16/01 - Frances Miller - Clause 5, tutorial - Frances Miller has volunteered to create a tutorial section for inclusion into the document.

11/16/01 - Jason Doege - Jason suggested that the JTAG 1149.1 standard has a way to assign device id's. Jason agreed to find out how it is done and report to the group. This need in 1450.3 is for the naming of "TESTER_ID" for use in Pattern->Resource statements and in Pragma blocks.

12/14/01 - Tony Taylor - Find a reference for regular expressions as used in the NameChecks block.

Agenda for next meeting:

1. Review of NameMaps for tester channel mapping
2. Review Signals Supply
3. Review Ken Posse's semantic descriptions
4. Other issues ?

Next Meeting: Friday 12/21 @ 1:15 PST.