May 22, 2007

From STDFGroup

STDF Scan datalog meeting Notes

Date: 22^nd^ May 2007

Attendees:

Glenn Plowman - Qualcomm

Ajay Khoche - Verigy

Phil Burlinson - Inovys

Cy Hay - Synopsys

Ping Wen - Yield Dynamics

Andreas Leininger – Infineon

John Rowe - Teradyne

Mary Israni - BCS

Tom Bartenstien - Cadence

Wu Yang - Mentor

Mani Balaraman - Advantest

Darrel Carder - Freescale

Agenda:

1. Discuss datamodel
2. Regular meeting duration
3. Meeting at Semicon

Minutes:

• Data Model Discussions
  • General
  • The discussion to focus on the requirement and not how the requirements will map on existing records v/s new records v/s a combination
    • In today's environment the database for scan fail datalog is separate from the tradition functional and parametric fails for (QC, Infineon, Freescale)
    • Should OptionalField in all data items be integer or Boolean. The decision will be taken during the mapping the information contents to records.
  • Device ID:
    • Add Lot ID to the pkg ID also for consistency purpose.
    • It is not clear how the Die ID will be obtained for the PKG ID record. The format will however support a filed for any environment that has means to get it.
  • Test Identification
    • There is an issue whether TestSuiteID should be a number or a string. There is a mechanism in existing STDF record to map a test site no to string in TSR. However the TestSuite numbering (Auto numbering) is not consistent across the ATE vendors and hence results in inconsistency anyway. Decision on string v/s number to be taken later.
    • The FEH information is nice to have but can be obtained from the existing STDF records.
    • There should be a flag added to the run\-time pattern map to indicate whether the pattern has been modified by the tester.
    • Cycle index and Pattern index should of type long instead of integer
  • Environment Specifications
    • The use model is that this info is available in the source file but any changes need to communicated.
    • The datain the environment block is meant to override the information in source pattern file
    • LOLS vs LOC indication should be made part of the pattern source file.
    • Frequency specification should be changed to time specifications
    • A single frequency specification is not sufficient
    • Frequency specification should on per clock domain basis as applied to a set of pins
    • The new structure for time specifications to include for each domain :
      • Domain Id
      • time, & unit,
      • internalflag:boolean (TO INDICATE ate DRIVEN OR INTERNAL
    • Similarly voltage specification should be on domains basis also to support multi\-Vdd designs.
    • The new structure for voltage specifications to include for each domain :
      • Domain Id
      • voltage & unit,
      • internalflag:boolean (TO INDICATE ate DRIVEN OR INTERNAL
  • Format Specification
    • Another field type should be added to the record to indicate whether a data dump is recorded instead of fails. The format for the data\-dump to be discusses. Phil to create an example.
    • Z\-handling flag should remain to support Z\- checking in the output to handle ATEs that can handle Z\-compare. Allowed options are as follows:
    • Fail data format, expected data and Data dump to be represented as a single enumeration field for expandability. An example enumeration is shown in the table below.

|Enumeration index|Fail Data|Expected Data Available|DataCapture/DataDump|

---

|0 |Cycle |No |No |

|1 |Cycle |No |Yes |

|2 |Cycle |Yes |No |

|3 |Cycle |Yes |Yes |

|4 |Pattern |No |No |

|5 |Pattern |No |Yes |

|6 |Pattern |Yes |No |

|7 |Pattern |Yes |Yes |

---

|Enumeration value|condition| |0 |Z mapped to L|

|1 |Z mapped to H|

|2 |Z mapped to Z|

|3 |Z mapped to X|

|4 |No handled|

• • Validation and Synchronization
    • There is a need to handle the testers that do not have per pin fail buffer. We can add a Boolean field to indicate that.
    • We need to support both fail data collection per cycle and fail data collection per pin
    • The last cycle/pattern logged information is available in the
    • We need to have way to indicate whether there were fails after the buffer became full.
  • How do handle patterns reloads? The issue is with cycle numbering? In case of reloads how the fail cycles are numbered.

Next Meeting:

• Next meeting on May 31st 8.00AM\-10.00AM

New Action Items:

• How to report capture time – Ajay, John and Mani
• Check on room availability at Semicon Wset – Ajay
• Create an Example for Data dump – Phil
• Review datamodel document \- All