Standardising STDF metadata
When a product goes into production, comparative yield and parametric data are important to help maintain or improve the yield while providing data to work with when investigating yield busts. When dealing with hundreds or even thousands of datalogs, the engineer would benefit from being able to aggregate and compare the data according to metadata values such as tester or lot-id or handler card number. Above is a chart comparing a key test for a product where wafers have been tested using two probe cards.
At yieldHUB, we sometimes get requests, especially from larger IDM customers and OSATs, to manually update datalogs or the corresponding database entry to correct certain fields like Lot_Id, Run_Type (e.g. final test, rescreen or QA) and other fields essential to grouping the data for analysis. The customer may have already spent a lot of time figuring out why a certain datalog doesn’t get included in reports only to discover that the operator mistyped a zero with an o or have carelessly pressed an extra key in the middle of the Lot_Id field. We had a case of incorrect consolidated yield calculation because the Run_Type was agreed to be the 5th field in one datalog had an extra dash character before the Run_Type field and that resulted to an incorrect value for the Run_Type. Another case was a typo error by an operator typing in an extra letter in the middle of the Lot_Id value.
Some companies who were used to analysing data on a per datalog basis didn’t mind incorrect or non-standard metadata. However, when doing volume analysis on yieldHUB, users quickly realise the need for having standardised metadata or it takes time to aggregate data by labelling the data on-line afterwards (which you can also do). In this case, it is important that steps should be taken to standardise datalog metadata as soon as possible.
Engineers responsible for monitoring yield should ensure that in production the metadata on the datalog files are completely filled in by operators. Companies should have standard field values and consistent procedures to ensure the fields are properly filled in with the correct values. When dealing with hundreds or even thousands of datalogs, the engineer would benefit from being able to aggregate and compare the data according to metadata values such as tester or lot-id or handler card number.
The top Offshore Assembly and Test (OSAT) subcontractors have procedures to make the metadata consistent and reliable but some of the smaller OSATs may not, so you may have to work more closely with these to make sure the meta data is entered consistently and correctly. The benefits are real in the amount of time saved in important root cause analysis later on.