1. XATF - eXtendible Adaptive Test Format Stefan Eichenberger 21 st June, 2010

2. Content The Need: Requirement corner-stones The Concept: Corner-stones of XATF Some More Details Conclusion and Discussion September 8, 2015Stefan Eichenberger 2

3. Scope: The Adaptive Test Universe September 8, 2015Stefan Eichenberger 3 How do we transport data here? ITRS Roadmap, 2009

4. STDF-v4 STDF-v4/2007 Data Functions Offline analysis and archiving –parametric data –bin and summary data –fail vector information adaptive test: real time analysis and optimization –decision documentation –statistical and model data adaptive test: automated off-line data analysis –down-stream processing recipe adaption –data feed-forward –SPC limit calculation / data feedback Device classification –assembly classification September 8, 2015Stefan Eichenberger, 4 To From WATEsortAsslyFinalBoard WAT Esort E-142 Assly Final Board Data Feedback SPC Data Feedforward Which tree was built and used? (PSU) Which neighborhood was chosen? (TI) Slope? Intercept? PCA transformation matrix?

5. Trends Some mature concepts –AEC Q001- Part average testing –statistical scan diagnosis Many concepts in their infancy –the unknown is the only constant factor … –the slow adoption rate of statistical scan diagnosis demonstrates how a lack of infrastructure capabilities can hinder broad-scale introduction Increased supply chain complexity –not all data should be sent to everywhere –… but exact flows vary and are very case specific Hence, we need: –a format with a well defined standard core (which must expand over time) –light-weight, transparent extendibility September 8, 2015Stefan Eichenberger 5

6. Requirements on a data format Open, royalty free format Clear, concise and complete core specification –definition of format (schema) –defined conformance checking –definition of key content elements Transparent extendibility –supporting forward- and backward compatibility –defined maintenance cycles Multi-way communication –“dock / un-dock“ chunks to a file as fit a given manufacturing flow Harvesting existing formats, where they exist (eg. E142) September 8, 2015Stefan Eichenberger 6 But can we define this all today? No, we don’t have to!

7. Can we fix STDF? STDF originates from an age where computers were far less powerful –remember 640kByte memory on 4.66MHz IBM PC? This dictated some compromises which were great then but a pain today: –file can only be read sequentially –record format is not extendible – leading to bloated files –binary encoding CPU specific STDF doesn’t have a robust core specification –no reference implementation or compliancy check Fixing STDF means breaking with history –many STDF applications (readers and writers) will likely not transparently handle extensions –hence, we get the costs of a new format without the benefits September 8, 2015Stefan Eichenberger 7 STDF was a great format! But its place is in history!

8. If we sweep the floor – what can we gain? Harvest modern software eco systems –ease of data handling –tap into larger human resource pool –schema language based format definition to allow coherent extendability Light-weight key infrastructure component –targeted data extraction with few lines of code –supporting low-cost proto-typing of adaptive test concepts Foundation to grow for years –… it’s not a question whether we drop STDF – it’s a question when we do it September 8, 2015Stefan Eichenberger 8

9. Content The Need: Requirement corner-stones The Concept: Corner-stones of XATF Some More Details Conclusion and Discussion September 8, 2015Stefan Eichenberger 9

10. What if we could … … use XML? –large eco-system of software, software components and knowlege –well established, rapidly increasing adaption rate in many areas –narrative we can express everything we want: lot descriptions, wafer layouts, adaptive test recipes, … perfectly suited to support data routing along a complex supply chain –but it’s huge! try this: Michael Hackerott described an XML version of STDFXML version of STDF a 1GByte STDF file grows to 6GByte …  Observation: –XML fits most of our needs – except the actual die specific data! –XML is not good at managing dense data (eg. results tables) September 8, 2015Stefan Eichenberger 10

11. What if we could … … use SQL right at the tester? –random access to large data sets –performance can be optimized through indices –good at handling dense data, such as results tables –… but what about narrative data lot descriptions recipes … data models quickly become very complex! –and do you really want a life data connection from the test cell to a corporate SQL database? (No!) How to handle real time requirements? Observations –would bring a relational database right to the tester –nice idea – but is it realistic? (Yes, it is!) September 8, 2015Stefan Eichenberger 11

12. The way to go … Both XML and SQL schemas can –be formally described –lend themselves to extendibility –are well understood by a large community of software engineers The only crux is to find how to combine them! September 8, 2015Stefan Eichenberger 12 SQLite is a self-contained, serverless, zero-configuration transactional SQL database portable file format (CPU independent) public domain license (no restrictions as eg. with GNU licences) wide industry adaption (eg. Adobe, Mozilla, …) sqlite.org

13. September 8, 2015Stefan Eichenberger 13 Concept XATF The basic data (narrative part) is stored in XML Dense data can not easily be stored in XML Such dense data is stored in base64 encoded binary containers at the end of the XML file –XML elements can refer to specific containers through a BulkID Typically, the internals of a bulk container are an SQLite database file Other bulk data can be allowed if needed –even encrypted data XATF NativeContainer @BulkID = 1 @BulkID = 2 @BulkID = 3 … some native content

14. So, all we need do is … Layer 0: Format definition –define a basic XML structure must be able to capture most if not all of STDF –define extension mechanisms XML schemas are by definition extendible namespaces allow infinite future growth how to differentiate between proprietary and public extensions –define access mechanism to bulk containers Level 1: Content definition –the essential data elements of the core structure must also be defined in terms of their exact meaning Migration path: Map STDF elements to XATF elements –it should be possible to have lossless conversions STDF  XATF  STDF (lossless in terms of information, not in exact STDF representation) September 8, 2015Stefan Eichenberger 14

15. September 8, 2015Stefan Eichenberger 15 Transition Management: STDF  XATF Large existing investments in STDF –infrastructure, tools (incl. deployment, user training, …) –historical data Transition requirements –loss-less conversion from STDF if converted back to STDF, same information must be present (although potentially in a different STDF representation) some (less relevant, t.b.d.) STDF corner cases will be difficult to support STDF[in]STDF[out] Other data XATF Other data Same or more information than in STDF[in]

16. Content The Need: Requirement corner-stones The Concept: Corner-stones of XATF Some More Details Conclusion and Discussion September 8, 2015Stefan Eichenberger 16

17. Top Level Structure September 8, 2015Stefan Eichenberger, WT&FO, Operations - 17

18. E142 embedding September 8, 2015Stefan Eichenberger, WT&FO, Operations - 18

19. Bulk Storage Simple data model: –part level data –substrate (wafer) level data –lot level data The table structure fits standard analysis tools and paradigms –Example: part specific limits are added as an additional column, just like a test result September 8, 2015Stefan Eichenberger, WT&FO, Operations - 19

20. Content The Need: Requirement corner-stones The Concept: Corner-stones of XATF Some More Details Conclusion and Discussion September 8, 2015Stefan Eichenberger 20

21. Summary Adaptive test is getting out of it’s infancy – time to give it a solid data communication back-bone the proposed combination of XML with bulk data storage in base64 encoded SQLite database format provides a solid foundation for a new format extendibility is guaranteed in three ways –extendible XML schemas for narrative data –extendible SQL structures for dense data –other bulk data formats where such is needed Proposal is to start with a small content coverage and define the extendibility mechanisms Care must be taken to also specify exact content of general content elements to avoid ambiguities as in STDF September 8, 2015Stefan Eichenberger 21